{"push_id":663625191,"size":67,"distinct_size":67,"ref":"refs/heads/REL9_3_STABLE","head":"96b676cc66c5a60a522364487bf7c7a9593bb229","before":"9ecd51da704b6c451fbf40bc30cd2aff1111eb92","commits":[{"sha":"6ef5d894a42646bdc480da88136fb2afd199e187","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix broken #ifdef for __sparcv8\n\nRob Rowan. Backpatch to all supported versions, like the patch that added\nthe broken #ifdef.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/6ef5d894a42646bdc480da88136fb2afd199e187"},{"sha":"d5f70a2d68d76a28c18facf22170e99d2a0301c6","author":{"email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","name":"Peter Eisentraut"},"message":"pg_regress: Write processed input/*.source into output dir\n\nBefore, it was writing the processed files into the input directory,\nwhich is incorrect in a vpath build.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/d5f70a2d68d76a28c18facf22170e99d2a0301c6"},{"sha":"4662ba5a23db39b695050afbcc5ff65ccd285179","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix null-pointer-deref crash while doing COPY IN with check constraints.\n\nIn commit bf7ca15875988a88e97302e012d7c4808bef3ea9 I introduced an\nassumption that an RTE referenced by a whole-row Var must have a valid eref\nfield.  This is false for RTEs constructed by DoCopy, and there are other\nplaces taking similar shortcuts.  Perhaps we should make all those places\ngo through addRangeTableEntryForRelation or its siblings instead of having\nad-hoc logic, but the most reliable fix seems to be to make the new code in\nExecEvalWholeRowVar cope if there's no eref.  We can reasonably assume that\nthere's no need to insert column aliases if no aliases were provided.\n\nAdd a regression test case covering this, and also verifying that a sane\ncolumn name is in fact available in this situation.\n\nAlthough the known case only crashes in 9.4 and HEAD, it seems prudent to\nback-patch the code change to 9.2, since all the ingredients for a similar\nfailure exist in the variant patch applied to 9.3 and 9.2.\n\nPer report from Jean-Pierre Pelletier.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/4662ba5a23db39b695050afbcc5ff65ccd285179"},{"sha":"7bc6e59546db93d975723cff7f19f3bffcefef6b","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix misuse of memcpy() in check_ip().\n\nThe previous coding copied garbage into a local variable, pretty much\nensuring that the intended test of an IPv6 connection address against a\npromoted IPv4 address from pg_hba.conf would never match.  The lack of\nfield complaints likely indicates that nobody realized this was supposed\nto work, which is unsurprising considering that no user-facing docs suggest\nit should work.\n\nIn principle this could have led to a SIGSEGV due to reading off the end of\nmemory, but since the source address would have pointed to somewhere in the\nfunction's stack frame, that's quite unlikely.  What led to discovery of\nthe bug is Hugo Osvaldo Barrera's report of a crash after an OS upgrade,\nwhich is probably because he is now running a system in which memcpy raises\nabort() upon detecting overlapping source and destination areas.  (You'd\nhave to additionally suppose some things about the stack frame layout to\narrive at this conclusion, but it seems plausible.)\n\nThis has been broken since the code was added, in commit f3aec2c7f51904e7,\nso back-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/7bc6e59546db93d975723cff7f19f3bffcefef6b"},{"sha":"9a90ec9cff34168994f5d544c2c3cc1b1ae21277","author":{"email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org","name":"Robert Haas"},"message":"Improve pg_check_dir code and comments.\n\nAvoid losing errno if readdir() fails and closedir() works.  Consistently\nreturn 4 rather than 3 if both a lost+found directory and other files are\nfound, rather than returning one value or the other depending on the\norder of the directory listing.  Update comments to match the actual\nbehavior.\n\nThese oversights date to commits 6f03927fce038096f53ca67eeab9adb24938f8a6\nand 17f15239325a88581bb4f9cf91d38005f1f52d69.\n\nMarco Nenciarini","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/9a90ec9cff34168994f5d544c2c3cc1b1ae21277"},{"sha":"4ea2d2ddbe247d529e9d51a362704d67c56f4e48","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Remove code to match IPv4 pg_hba.conf entries to IPv4-in-IPv6 addresses.\n\nIn investigating yesterday's crash report from Hugo Osvaldo Barrera, I only\nlooked back as far as commit f3aec2c7f51904e7 where the breakage occurred\n(which is why I thought the IPv4-in-IPv6 business was undocumented).  But\nactually the logic dates back to commit 3c9bb8886df7d56a and was simply\nbroken by erroneous refactoring in the later commit.  A bit of archives\nexcavation shows that we added the whole business in response to a report\nthat some 2003-era Linux kernels would report IPv4 connections as having\nIPv4-in-IPv6 addresses.  The fact that we've had no complaints since 9.0\nseems to be sufficient confirmation that no modern kernels do that, so\nlet's just rip it all out rather than trying to fix it.\n\nDo this in the back branches too, thus essentially deciding that our\neffective behavior since 9.0 is correct.  If there are any platforms on\nwhich the kernel reports IPv4-in-IPv6 addresses as such, yesterday's fix\nwould have made for a subtle and potentially security-sensitive change in\nthe effective meaning of IPv4 pg_hba.conf entries, which does not seem like\na good thing to do in minor releases.  So let's let the post-9.0 behavior\nstand, and change the documentation to match it.\n\nIn passing, I failed to resist the temptation to wordsmith the description\nof pg_hba.conf IPv4 and IPv6 address entries a bit.  A lot of this text\nhasn't been touched since we were IPv4-only.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/4ea2d2ddbe247d529e9d51a362704d67c56f4e48"},{"sha":"a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix failure to honor -Z compression level option in pg_dump -Fd.\n\ncfopen() and cfopen_write() failed to pass the compression level through\nto zlib, so that you always got the default compression level if you got\nany at all.\n\nIn passing, also fix these and related functions so that the correct errno\nis reliably returned on failure; the original coding supposes that free()\ncannot change errno, which is untrue on at least some platforms.\n\nPer bug #12779 from Christoph Berg.  Back-patch to 9.1 where the faulty\ncode was introduced.\n\nMichael Paquier","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911"},{"sha":"a196e67f930e0fef10928928122770d59b14b653","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Fix object identities for pg_conversion objects\n\nWe were neglecting to schema-qualify them.\n\nBackpatch to 9.3, where object identities were introduced as a concept\nby commit f8348ea32ec8.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/a196e67f930e0fef10928928122770d59b14b653"},{"sha":"f389b6e0a7637de014e5ea1adbcfa50108bb4e58","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix misparsing of empty value in conninfo_uri_parse_params().\n\nAfter finding an \"=\" character, the pointer was advanced twice when it\nshould only advance once.  This is harmless as long as the value after \"=\"\nhas at least one character; but if it doesn't, we'd miss the terminator\ncharacter and include too much in the value.\n\nIn principle this could lead to reading off the end of memory.  It does not\nseem worth treating as a security issue though, because it would happen on\nclient side, and besides client logic that's taking conninfo strings from\nuntrusted sources has much worse security problems than this.\n\nReport and patch received off-list from Thomas Fanghaenel.\nBack-patch to 9.2 where the faulty code was introduced.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/f389b6e0a7637de014e5ea1adbcfa50108bb4e58"},{"sha":"cdf813c59312298194b16eecc68aa50c9e2e1133","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix potential deadlock with libpq non-blocking mode.\n\nIf libpq output buffer is full, pqSendSome() function tries to drain any\nincoming data. This avoids deadlock, if the server e.g. sends a lot of\nNOTICE messages, and blocks until we read them. However, pqSendSome() only\ndid that in blocking mode. In non-blocking mode, the deadlock could still\nhappen.\n\nTo fix, take a two-pronged approach:\n\n1. Change the documentation to instruct that when PQflush() returns 1, you\nshould wait for both read- and write-ready, and call PQconsumeInput() if it\nbecomes read-ready. That fixes the deadlock, but applications are not going\nto change overnight.\n\n2. In pqSendSome(), drain the input buffer before returning 1. This\nalleviates the problem for applications that only wait for write-ready. In\nparticular, a slow but steady stream of NOTICE messages during COPY FROM\nSTDIN will no longer cause a deadlock. The risk remains that the server\nattempts to send a large burst of data and fills its output buffer, and at\nthe same time the client also sends enough data to fill its output buffer.\nThe application will deadlock if it goes to sleep, waiting for the socket\nto become write-ready, before the server's data arrives. In practice,\nNOTICE messages and such that the server might be sending are usually\nshort, so it's highly unlikely that the server would fill its output buffer\nso quickly.\n\nBackpatch to all supported versions.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/cdf813c59312298194b16eecc68aa50c9e2e1133"},{"sha":"a6ddff81226aa39a610de1ff312dcbc0e4b9fa4d","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Guard against spurious signals in LockBufferForCleanup.\n\nWhen LockBufferForCleanup() has to wait for getting a cleanup lock on a\nbuffer it does so by setting a flag in the buffer header and then wait\nfor other backends to signal it using ProcWaitForSignal().\nUnfortunately LockBufferForCleanup() missed that ProcWaitForSignal() can\nreturn for other reasons than the signal it is hoping for. If such a\nspurious signal arrives the wait flags on the buffer header will still\nbe set. That then triggers \"ERROR: multiple backends attempting to wait\nfor pincount 1\".\n\nThe fix is simple, unset the flag if still set when retrying. That\nimplies an additional spinlock acquisition/release, but that's unlikely\nto matter given the cost of waiting for a cleanup lock.  Alternatively\nit'd have been possible to move responsibility for maintaining the\nrelevant flag to the waiter all together, but that might have had\nnegative consequences due to possible floods of signals. Besides being\nmore invasive.\n\nThis looks to be a very longstanding bug. The relevant code in\nLockBufferForCleanup() hasn't changed materially since its introduction\nand ProcWaitForSignal() was documented to return for unrelated reasons\nsince 8.2.  The master only patch series removing ImmediateInterruptOK\nmade it much easier to hit though, as ProcSendSignal/ProcWaitForSignal\nnow uses a latch shared with other tasks.\n\nPer discussion with Kevin Grittner, Tom Lane and me.\n\nBackpatch to all supported branches.\n\nDiscussion: 11553.1423805224@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/a6ddff81226aa39a610de1ff312dcbc0e4b9fa4d"},{"sha":"f864fe07403e6d6b38a06490c01a62a41872899a","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix dumping of views that are just VALUES(...) but have column aliases.\n\nThe \"simple\" path for printing VALUES clauses doesn't work if we need\nto attach nondefault column aliases, because there's noplace to do that\nin the minimal VALUES() syntax.  So modify get_simple_values_rte() to\ndetect nondefault aliases and treat that as a non-simple case.  This\nfurther exposes that the \"non-simple\" path never actually worked;\nit didn't produce valid syntax.  Fix that too.  Per bug #12789 from\nCurtis McEnroe, and analysis by Andrew Gierth.\n\nBack-patch to all supported branches.  Before 9.3, this also requires\nback-patching the part of commit 092d7ded29f36b0539046b23b81b9f0bf2d637f1\nthat created get_simple_values_rte() to begin with; inserting the extra\ntest into the old factorization of that logic would've been too messy.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/f864fe07403e6d6b38a06490c01a62a41872899a"},{"sha":"4651e37cb1c9cc34643921bdc8b783d1c81b488f","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Free SQLSTATE and SQLERRM no earlier than other PL/pgSQL variables.\n\n\"RETURN SQLERRM\" prompted plpgsql_exec_function() to read from freed\nmemory.  Back-patch to 9.0 (all supported versions).  Little code ran\nbetween the premature free and the read, so non-assert builds are\nunlikely to witness user-visible consequences.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/4651e37cb1c9cc34643921bdc8b783d1c81b488f"},{"sha":"abce8dc7d6d8e30f2d4b02219eb73c205e5bf199","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Reconsider when to wait for WAL flushes/syncrep during commit.\n\nUp to now RecordTransactionCommit() waited for WAL to be flushed (if\nsynchronous_commit != off) and to be synchronously replicated (if\nenabled), even if a transaction did not have a xid assigned. The primary\nreason for that is that sequence's nextval() did not assign a xid, but\nare worthwhile to wait for on commit.\n\nThis can be problematic because sometimes read only transactions do\nwrite WAL, e.g. HOT page prune records. That then could lead to read only\ntransactions having to wait during commit. Not something people expect\nin a read only transaction.\n\nThis lead to such strange symptoms as backends being seemingly stuck\nduring connection establishment when all synchronous replicas are\ndown. Especially annoying when said stuck connection is the standby\ntrying to reconnect to allow syncrep again...\n\nThis behavior also is involved in a rather complicated <= 9.4 bug where\nthe transaction started by catchup interrupt processing waited for\nsyncrep using latches, but didn't get the wakeup because it was already\nrunning inside the same overloaded signal handler. Fix the issue here\ndoesn't properly solve that issue, merely papers over the problems. In\n9.5 catchup interrupts aren't processed out of signal handlers anymore.\n\nTo fix all this, make nextval() acquire a top level xid, and only wait for\ntransaction commit if a transaction both acquired a xid and emitted WAL\nrecords.  If only a xid has been assigned we don't uselessly want to\nwait just because of writes to temporary/unlogged tables; if only WAL\nhas been written we don't want to wait just because of HOT prunes.\n\nThe xid assignment in nextval() is unlikely to cause overhead in\nreal-world workloads. For one it only happens SEQ_LOG_VALS/32 values\nanyway, for another only usage of nextval() without using the result in\nan insert or similar is affected.\n\nDiscussion: 20150223165359.GF30784@awork2.anarazel.de,\n    369698E947874884A77849D8FE3680C2@maumau,\n    5CF4ABBA67674088B3941894E22A0D25@maumau\n\nPer complaint from maumau and Thom Brown\n\nBackpatch all the way back; 9.0 doesn't have syncrep, but it seems\nbetter to be consistent behavior across all maintained branches.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/abce8dc7d6d8e30f2d4b02219eb73c205e5bf199"},{"sha":"1b558782b7156bac9b4012ccee5338f1ccd236d9","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix planning of star-schema-style queries.\n\nPart of the intent of the parameterized-path mechanism was to handle\nstar-schema queries efficiently, but some overly-restrictive search\nlimiting logic added in commit e2fa76d80ba571d4de8992de6386536867250474\nprevented such cases from working as desired.  Fix that and add a\nregression test about it.  Per gripe from Marc Cousin.\n\nThis is arguably a bug rather than a new feature, so back-patch to 9.2\nwhere parameterized paths were introduced.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/1b558782b7156bac9b4012ccee5338f1ccd236d9"},{"sha":"585f16dc80337a2ee7b0e823c7ff42a9e10d1d88","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Unlink static libraries before rebuilding them.\n\nWhen the library already exists in the build directory, \"ar\" preserves\nmembers not named on its command line.  This mattered when, for example,\na \"configure\" rerun dropped a file from $(LIBOBJS).  libpgport carried\nthe obsolete member until \"make clean\".  Back-patch to 9.0 (all\nsupported versions).","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/585f16dc80337a2ee7b0e823c7ff42a9e10d1d88"},{"sha":"43d81f16a393cbc233bbb5d8314c4148cf5a5d68","author":{"email":"d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net","name":"Stephen Frost"},"message":"Fix pg_dump handling of extension config tables\n\nSince 9.1, we've provided extensions with a way to denote\n\"configuration\" tables- tables created by an extension which the user\nmay modify.  By marking these as \"configuration\" tables, the extension\nis asking for the data in these tables to be pg_dump'd (tables which\nare not marked in this way are assumed to be entirely handled during\nCREATE EXTENSION and are not included at all in a pg_dump).\n\nUnfortunately, pg_dump neglected to consider foreign key relationships\nbetween extension configuration tables and therefore could end up\ntrying to reload the data in an order which would cause FK violations.\n\nThis patch teaches pg_dump about these dependencies, so that the data\ndumped out is done so in the best order possible.  Note that there's no\nway to handle circular dependencies, but those have yet to be seen in\nthe wild.\n\nThe release notes for this should include a caution to users that\nexisting pg_dump-based backups may be invalid due to this issue.  The\ndata is all there, but restoring from it will require extracting the\ndata for the configuration tables and then loading them in the correct\norder by hand.\n\nDiscussed initially back in bug #6738, more recently brought up by\nGilles Darold, who provided an initial patch which was further reworked\nby Michael Paquier.  Further modifications and documentation updates\nby me.\n\nBack-patch to 9.1 where we added the concept of extension configuration\ntables.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/43d81f16a393cbc233bbb5d8314c4148cf5a5d68"},{"sha":"73f236f5793e25f04933247917092de39011afd9","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Add comment for \"is_internal\" parameter\n\nThis was missed in my commit f4c4335 of 9.3 vintage, so backpatch to\nthat.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/73f236f5793e25f04933247917092de39011afd9"},{"sha":"5cf4000034fb75de2b09642b9d37ee50f708090a","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Fix user mapping object description\n\nWe were using \"user mapping for user XYZ\" as description for user mappings, but\nthat's ambiguous because users can have mappings on multiple foreign\nservers; therefore change it to \"for user XYZ on server UVW\" instead.\nObject identities for user mappings are also updated in the same way, in\nbranches 9.3 and above.\n\nThe incomplete description string was introduced together with the whole\nSQL/MED infrastructure by commit cae565e503 of 8.4 era, so backpatch all\nthe way back.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/5cf4000034fb75de2b09642b9d37ee50f708090a"},{"sha":"49bb34382d31710f28819e1317a1a05ba744b70a","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Fix contrib/file_fdw's expected file\n\nI forgot to update it on yesterday's cf34e373fcf.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/49bb34382d31710f28819e1317a1a05ba744b70a"}]}