{"push_id":3142679350,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/21/1886","head":"f0824ab46e5b97044c008975ba7baa13cf38fe71","before":"03c18330ef298174c5be01b5a5c0fb49056bada8","commits":[{"sha":"ade2d61ed09c11a3d374a98c66c8a05cb82a0069","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Improve detection of child-process SIGPIPE failures.\n\nCommit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child\nprocess, but it only worked correctly if the SIGPIPE occurred in the\nimmediate child process.  Depending on the shell in use and the\ncomplexity of the shell command string, we might instead get back\nan exit code of 128 + SIGPIPE, representing a shell error exit\nreporting SIGPIPE in the child process.\n\nWe could just hack up ClosePipeToProgram() to add the extra case,\nbut it seems like this is a fairly general issue deserving a more\ngeneral and better-documented solution.  I chose to add a couple\nof functions in src/common/wait_error.c, which is a natural place\nto know about wait-result encodings, that will test for either a\nspecific child-process signal type or any child-process signal failure.\nThen, adjust other places that were doing ad-hoc tests of this type\nto use the common functions.\n\nIn RestoreArchivedFile, this fixes a race condition affecting whether\nthe process will report an error or just silently proc_exit(1): before,\nthat depended on whether the intermediate shell got SIGTERM'd itself\nor reported a child process failing on SIGTERM.\n\nLike the previous patch, back-patch to v10; we could go further\nbut there seems no real need to.\n\nPer report from Erik Rijkers.\n\nDiscussion: https://postgr.es/m/f3683f87ab1701bea5d86a7742b22432@xs4all.nl","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ade2d61ed09c11a3d374a98c66c8a05cb82a0069"},{"sha":"16fda4b853cd5bc07c450303a465ed9d451c7b47","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make error handling in parallel pg_upgrade less bogus.\n\nreap_child() basically ignored the possibility of either an error in\nwaitpid() itself or a child process failure on signal.  We don't really\nneed to do more than report and crash hard, but proceeding as though\nnothing is wrong is definitely Not Acceptable.  The error report for\nnonzero child exit status was pretty off-point, as well.\n\nNoted while fooling around with child-process failure detection\nlogic elsewhere.  It's been like this a long time, so back-patch to\nall supported branches.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/16fda4b853cd5bc07c450303a465ed9d451c7b47"},{"sha":"a73d08319537d807a520a72bc5bd17279672c3de","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Modernize our code for looking up descriptive strings for Unix signals.\n\nAt least as far back as the 2008 spec, POSIX has defined strsignal(3)\nfor looking up descriptive strings for signal numbers.  We hadn't gotten\nthe word though, and were still using the crufty old sys_siglist array,\nwhich is in no standard even though most Unixen provide it.\n\nAside from not being formally standards-compliant, this was just plain\nugly because it involved #ifdef's at every place using the code.\n\nTo eliminate the #ifdef's, create a portability function pg_strsignal,\nwhich wraps strsignal(3) if available and otherwise falls back to\nsys_siglist[] if available.  The set of Unixen with neither API is\nprobably empty these days, but on any platform with neither, you'll\njust get \"unrecognized signal\".  All extant callers print the numeric\nsignal number too, so no need to work harder than that.\n\nAlong the way, upgrade pg_basebackup's child-error-exit reporting\nto match the rest of the system.\n\nDiscussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a73d08319537d807a520a72bc5bd17279672c3de"},{"sha":"b13fd344c5fce6a2f95b758e97b79eb00adf2731","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Make constraint rename issue relcache invalidation on target relation\n\nWhen a constraint gets renamed, it may have associated with it a target\nrelation (for example domain constraints don't have one).  Not\ninvalidating the target relation cache when issuing the renaming can\nresult in issues with subsequent commands that refer to the old\nconstraint name using the relation cache, causing various failures.  One\npattern spotted was using CREATE TABLE LIKE after a constraint\nrenaming.\n\nReported-by: Stuart <sfbarbee@gmail.com>\nAuthor: Amit Langote\nReviewed-by: Michael Paquier\nDiscussion: https://postgr.es/m/2047094.V130LYfLq4@station53.ousa.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b13fd344c5fce6a2f95b758e97b79eb00adf2731"},{"sha":"67915fb8e51692ae92622696ad03e933be224bf2","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix use-after-free bug when renaming constraints\n\nThis is an oversight from recent commit b13fd344.  While on it, tweak\nthe previous test with a better name for the renamed primary key.\n\nDetected by buildfarm member prion which forces relation cache release\nwith -DRELCACHE_FORCE_RELEASE.  Back-patch down to 9.4 as the previous\ncommit.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/67915fb8e51692ae92622696ad03e933be224bf2"},{"sha":"f0824ab46e5b97044c008975ba7baa13cf38fe71","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 21/1886] Pass COPT and PROFILE to CXXFLAGS\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread, and also periodically to check for bitrot caused by changes\non the master branch.\n\nCommitfest entry: https://commitfest.postgresql.org/21/1886\nPatch(es): https://www.postgresql.org/message-id/20181113104005.GA32154@msg.credativ.de\nAuthor(s): Christoph Berg","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f0824ab46e5b97044c008975ba7baa13cf38fe71"}]}
{"actor":{"display_login":"postgresql-cfbot"}}