{"push_id":891357520,"size":21,"distinct_size":21,"ref":"refs/heads/REL9_3_STABLE","head":"fd52958856233bc3248db879c4241bdf08075c42","before":"7cecabca8fdc0ced666369a37b45df3182886230","commits":[{"sha":"71b1a0ab5f6b2f0fe87b4cb0f610508786731b6b","author":{"email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org","name":"Robert Haas"},"message":"Fix incorrect message in ATWrongRelkindError.\n\nMistake introduced by commit 3bf3ab8c563699138be02f9dc305b7b77a724307.\n\nEtsuro Fujita","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/71b1a0ab5f6b2f0fe87b4cb0f610508786731b6b"},{"sha":"18479293cbc531209dbdf68f94cd7f86b5290a80","author":{"email":"bc8b30e646d18e0af86ef37f859648a650cc276d@postgresql.org","name":"Kevin Grittner"},"message":"Fix serialization anomalies due to race conditions on INSERT.\n\nOn insert the CheckForSerializableConflictIn() test was performed\nbefore the page(s) which were going to be modified had been locked\n(with an exclusive buffer content lock).  If another process\nacquired a relation SIReadLock on the heap and scanned to a page on\nwhich an insert was going to occur before the page was so locked,\na rw-conflict would be missed, which could allow a serialization\nanomaly to be missed.  The window between the check and the page\nlock was small, so the bug was generally not noticed unless there\nwas high concurrency with multiple processes inserting into the\nsame table.\n\nThis was reported by Peter Bailis as bug #11732, by Sean Chittenden\nas bug #13667, and by others.\n\nThe race condition was eliminated in heap_insert() by moving the\ncheck down below the acquisition of the buffer lock, which had been\nthe very next statement.  Because of the loop locking and unlocking\nmultiple buffers in heap_multi_insert() a check was added after all\ninserts were completed.  The check before the start of the inserts\nwas left because it might avoid a large amount of work to detect a\nserialization anomaly before performing the all of the inserts and\nthe related WAL logging.\n\nWhile investigating this bug, other SSI bugs which were even harder\nto hit in practice were noticed and fixed, an unnecessary check\n(covered by another check, so redundant) was removed from\nheap_update(), and comments were improved.\n\nBack-patch to all supported branches.\n\nKevin Grittner and Thomas Munro","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/18479293cbc531209dbdf68f94cd7f86b5290a80"},{"sha":"909a83df561246538e97c582521243025b78c161","author":{"email":"bc8b30e646d18e0af86ef37f859648a650cc276d@postgresql.org","name":"Kevin Grittner"},"message":"Add RMV to list of commands taking AE lock.\n\nBackpatch to 9.3, where it was initially omitted.\n\nCraig Ringer, with minor adjustment by Kevin Grittner","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/909a83df561246538e97c582521243025b78c161"},{"sha":"8db652359c1739d4fc216d7f780c149671ed83c5","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix enforcement of restrictions inside regexp lookaround constraints.\n\nLookahead and lookbehind constraints aren't allowed to contain backrefs,\nand parentheses within them are always considered non-capturing.  Or so\nsays the manual.  But the regexp parser forgot about these rules once\ninside a parenthesized subexpression, so that constructs like (\\w)(?=(\\1))\nwere accepted (but then not correctly executed --- a case like this acted\nlike (\\w)(?=\\w), without any enforcement that the two \\w's match the same\ntext).  And in (?=((foo))) the innermost parentheses would be counted as\ncapturing parentheses, though no text would ever be captured for them.\n\nTo fix, properly pass down the \"type\" argument to the recursive invocation\nof parse().\n\nBack-patch to all supported branches; it was agreed that silent\nmisexecution of such patterns is worse than throwing an error, even though\nnew errors in minor releases are generally not desirable.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/8db652359c1739d4fc216d7f780c149671ed83c5"},{"sha":"34725292d92d1ba643f46957803b45c3554b5d42","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Don't connect() to a wildcard address in test_postmaster_connection().\n\nAt least OpenBSD, NetBSD, and Windows don't support it.  This repairs\npg_ctl for listen_addresses='0.0.0.0' and listen_addresses='::'.  Since\npg_ctl prefers to test a Unix-domain socket, Windows users are most\nlikely to need this change.  Back-patch to 9.1 (all supported versions).\nThis could change pg_ctl interaction with loopback-interface firewall\nrules.  Therefore, in 9.4 and earlier (released branches), activate the\nchange only on known-affected platforms.\n\nReported (bug #13611) and designed by Kondo Yuta.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/34725292d92d1ba643f46957803b45c3554b5d42"},{"sha":"baa42287a04d4cd2ffa529a07ed7e23421e742ae","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Improve our workaround for 'TeX capacity exceeded' in building PDF files.\n\nIn commit a5ec86a7c787832d28d5e50400ec96a5190f2555 I wrote a quick hack\nthat reduced the number of TeX string pool entries created while converting\nour documentation to PDF form.  That held the fort for awhile, but as of\nHEAD we're back up against the same limitation.  It turns out that the\noriginal coding of \\FlowObjectSetup actually results in *three* string pool\nentries being generated for every \"flow object\" (that is, potential\ncross-reference target) in the documentation, and my previous hack only got\nrid of one of them.  With a little more care, we can reduce the string\ncount to one per flow object plus one per actually-cross-referenced flow\nobject (about 115000 + 5000 as of current HEAD); that should work until\nthe documentation volume roughly doubles from where it is today.\n\nAs a not-incidental side benefit, this change also causes pdfjadetex to\nstop emitting unreferenced hyperlink anchors (bookmarks) into the PDF file.\nIt had been making one willy-nilly for every flow object; now it's just one\nper actually-cross-referenced object.  This results in close to a 2X\nsavings in PDF file size.  We will still want to run the output through\n\"jpdftweak\" to get it to be compressed; but we no longer need removal of\nunreferenced bookmarks, so we might be able to find a quicker tool for\nthat step.\n\nAlthough the failure only affects HEAD and US-format output at the moment,\n9.5 cannot be more than a few pages short of failing likewise, so it\nwill inevitably fail after a few rounds of minor-version release notes.\nI don't have a lot of faith that we'll never hit the limit in the older\nbranches; and anyway it would be nice to get rid of jpdftweak across the\nboard.  Therefore, back-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/baa42287a04d4cd2ffa529a07ed7e23421e742ae"},{"sha":"db6e8e1624a8f0357373450136c850f2b6e7fc8a","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix unwanted flushing of libpq's input buffer when socket EOF is seen.\n\nIn commit 210eb9b743c0645d I centralized libpq's logic for closing down\nthe backend communication socket, and made the new pqDropConnection\nroutine always reset the I/O buffers to empty.  Many of the call sites\npreviously had not had such code, and while that amounted to an oversight\nin some cases, there was one place where it was intentional and necessary\n*not* to flush the input buffer: pqReadData should never cause that to\nhappen, since we probably still want to process whatever data we read.\n\nThis is the true cause of the problem Robert was attempting to fix in\nc3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final\nERROR message before reporting \"server closed the connection unexpectedly\".\nBut that only accidentally fixed it, by invoking parseInput before the\ninput buffer got flushed; and very likely there are timing scenarios\nwhere we'd still lose the message before processing it.\n\nTo fix, pass a flag to pqDropConnection to tell it whether to flush the\ninput buffer or not.  On review I think flushing is actually correct for\nevery other call site.\n\nBack-patch to 9.3 where the problem was introduced.  In HEAD, also improve\nthe comments added by c3e7c24a1d60dc6a.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/db6e8e1624a8f0357373450136c850f2b6e7fc8a"},{"sha":"a75efb483649a194d4578404ca294735829ff127","author":{"email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@momjian.us","name":"Bruce Momjian"},"message":"pg_upgrade:  properly detect file copy failure on Windows\n\nPreviously, file copy failures were ignored on Windows due to an\nincorrect return value check.\n\nReport by Manu Joye\n\nBackpatch through 9.1","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/a75efb483649a194d4578404ca294735829ff127"},{"sha":"a37ab812c7a2a99917e01f07ac4958712ea02637","author":{"email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","name":"Peter Eisentraut"},"message":"PL/Python: Make tests pass with Python 3.5\n\nThe error message wording for AttributeError has changed in Python 3.5.\nFor the plpython_error test, add a new expected file.  In the\nplpython_subtransaction test, we didn't really care what the exception\nis, only that it is something coming from Python.  So use a generic\nexception instead, which has a message that doesn't vary across\nversions.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/a37ab812c7a2a99917e01f07ac4958712ea02637"},{"sha":"7d0e8720865321fcf124eaac6ef22ef22d13b957","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix ruleutils.c's dumping of whole-row Vars in ROW() and VALUES() contexts.\n\nNormally ruleutils prints a whole-row Var as \"foo.*\".  We already knew that\nthat doesn't work at top level of a SELECT list, because the parser would\ntreat the \"*\" as a directive to expand the reference into separate columns,\nnot a whole-row Var.  However, Joshua Yanovski points out in bug #13776\nthat the same thing happens at top level of a ROW() construct; and some\nnosing around in the parser shows that the same is true in VALUES().\nHence, apply the same workaround already devised for the SELECT-list case,\nnamely to add a forced cast to the appropriate rowtype in these cases.\n(The alternative of just printing \"foo\" was rejected because it is\ndifficult to avoid ambiguity against plain columns named \"foo\".)\n\nBack-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/7d0e8720865321fcf124eaac6ef22ef22d13b957"},{"sha":"faf18a90506ecf0a4ab1349acfcb899167385649","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Speed up ruleutils' name de-duplication code, and fix overlength-name case.\n\nSince commit 11e131854f8231a21613f834c40fe9d046926387, ruleutils.c has\nattempted to ensure that each RTE in a query or plan tree has a unique\nalias name.  However, the code that was added for this could be quite slow,\neven as bad as O(N^3) if N identical RTE names must be replaced, as noted\nby Jeff Janes.  Improve matters by building a transient hash table within\nset_rtable_names.  The hash table in itself reduces the cost of detecting a\nduplicate from O(N) to O(1), and we can save another factor of N by storing\nthe number of de-duplicated names already created for each entry, so that\nwe don't have to re-try names already created.  This way is probably a bit\nslower overall for small range tables, but almost by definition, such cases\nshould not be a performance problem.\n\nIn principle the same problem applies to the column-name-de-duplication\ncode; but in practice that seems to be less of a problem, first because\nN is limited since we don't support extremely wide tables, and second\nbecause duplicate column names within an RTE are fairly rare, so that in\npractice the cost is more like O(N^2) not O(N^3).  It would be very much\nmessier to fix the column-name code, so for now I've left that alone.\n\nAn independent problem in the same area was that the de-duplication code\npaid no attention to the identifier length limit, and would happily produce\nidentifiers that were longer than NAMEDATALEN and wouldn't be unique after\ntruncation to NAMEDATALEN.  This could result in dump/reload failures, or\nperhaps even views that silently behaved differently than before.  We can\nfix that by shortening the base name as needed.  Fix it for both the\nrelation and column name cases.\n\nIn passing, check for interrupts in set_rtable_names, just in case it's\nstill slow enough to be an issue.\n\nBack-patch to 9.3 where this code was introduced.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/faf18a90506ecf0a4ab1349acfcb899167385649"},{"sha":"7df6dc4056acc477d792bf3bb1a58eb3c1047269","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix possible internal overflow in numeric division.\n\ndiv_var_fast() postpones propagating carries in the same way as mul_var(),\nso it has the same corner-case overflow risk we fixed in 246693e5ae8a36f0,\nnamely that the size of the carries has to be accounted for when setting\nthe threshold for executing a carry propagation step.  We've not devised\na test case illustrating the brokenness, but the required fix seems clear\nenough.  Like the previous fix, back-patch to all active branches.\n\nDean Rasheed","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/7df6dc4056acc477d792bf3bb1a58eb3c1047269"},{"sha":"ae81d4fb19baa6409e1a86b3e5c22009ee8d0052","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Accept flex > 2.5.x in configure.\n\nPer buildfarm member anchovy, 2.6.0 exists in the wild now.\nHopefully it works with Postgres; if not, we'll have to do something\nabout that, but in any case claiming it's \"too old\" is pretty silly.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/ae81d4fb19baa6409e1a86b3e5c22009ee8d0052"},{"sha":"64349f1d29dc6257551c7663526fc6633b45e90b","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix handling of inherited check constraints in ALTER COLUMN TYPE (again).\n\nThe previous way of reconstructing check constraints was to do a separate\n\"ALTER TABLE ONLY tab ADD CONSTRAINT\" for each table in an inheritance\nhierarchy.  However, that way has no hope of reconstructing the check\nconstraints' own inheritance properties correctly, as pointed out in\nbug #13779 from Jan Dirk Zijlstra.  What we should do instead is to do\na regular \"ALTER TABLE\", allowing recursion, at the topmost table that\nhas a particular constraint, and then suppress the work queue entries\nfor inherited instances of the constraint.\n\nAnnoyingly, we'd tried to fix this behavior before, in commit 5ed6546cf,\nbut we failed to notice that it wasn't reconstructing the pg_constraint\nfield values correctly.\n\nAs long as I'm touching pg_get_constraintdef_worker anyway, tweak it to\nalways schema-qualify the target table name; this seems like useful backup\nto the protections installed by commit 5f173040.\n\nIn HEAD/9.5, get rid of get_constraint_relation_oids, which is now unused.\n(I could alternatively have modified it to also return conislocal, but that\nseemed like a pretty single-purpose API, so let's not pretend it has some\nother use.)  It's unused in the back branches as well, but I left it in\nplace just in case some third-party code has decided to use it.\n\nIn HEAD/9.5, also rename pg_get_constraintdef_string to\npg_get_constraintdef_command, as the previous name did nothing to explain\nwhat that entry point did differently from others (and its comment was\nequally useless).  Again, that change doesn't seem like material for\nback-patching.\n\nI did a bit of re-pgindenting in tablecmds.c in HEAD/9.5, as well.\n\nOtherwise, back-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/64349f1d29dc6257551c7663526fc6633b45e90b"},{"sha":"0e6185283c62fc1394ee6242a496fc727fe1136d","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Adopt the GNU convention for handling tar-archive members exceeding 8GB.\n\nThe POSIX standard for tar headers requires archive member sizes to be\nprinted in octal with at most 11 digits, limiting the representable file\nsize to 8GB.  However, GNU tar and apparently most other modern tars\nsupport a convention in which oversized values can be stored in base-256,\nallowing any practical file to be a tar member.  Adopt this convention\nto remove two limitations:\n* pg_dump with -Ft output format failed if the contents of any one table\nexceeded 8GB.\n* pg_basebackup failed if the data directory contained any file exceeding\n8GB.  (This would be a fatal problem for installations configured with a\ntable segment size of 8GB or more, and it has also been seen to fail when\nlarge core dump files exist in the data directory.)\n\nFile sizes under 8GB are still printed in octal, so that no compatibility\nissues are created except in cases that would have failed entirely before.\n\nIn addition, this patch fixes several bugs in the same area:\n\n* In 9.3 and later, we'd defined tarCreateHeader's file-size argument as\nsize_t, which meant that on 32-bit machines it would write a corrupt tar\nheader for file sizes between 4GB and 8GB, even though no error was raised.\nThis broke both \"pg_dump -Ft\" and pg_basebackup for such cases.\n\n* pg_restore from a tar archive would fail on tables of size between 4GB\nand 8GB, on machines where either \"size_t\" or \"unsigned long\" is 32 bits.\nThis happened even with an archive file not affected by the previous bug.\n\n* pg_basebackup would fail if there were files of size between 4GB and 8GB,\neven on 64-bit machines.\n\n* In 9.3 and later, \"pg_basebackup -Ft\" failed entirely, for any file size,\non 64-bit big-endian machines.\n\nIn view of these potential data-loss bugs, back-patch to all supported\nbranches, even though removal of the documented 8GB limit might otherwise\nbe considered a new feature rather than a bug fix.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/0e6185283c62fc1394ee6242a496fc727fe1136d"},{"sha":"6638c9aaf881b156fafc05371e8ed21f0cdda66e","author":{"email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@momjian.us","name":"Bruce Momjian"},"message":"pg_upgrade:  fix CopyFile() on Windows to fail on file existence\n\nAlso fix getErrorText() to return the right error string on failure.\nThis behavior now matches that of other operating systems.\n\nReport by Noah Misch\n\nBackpatch through 9.1","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/6638c9aaf881b156fafc05371e8ed21f0cdda66e"},{"sha":"64b7079e50cc75fc0e8730793b4a66bfb7388de2","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Be more paranoid about null return values from libpq status functions.\n\nPQhost() can return NULL in non-error situations, namely when a Unix-socket\nconnection has been selected by default.  That behavior is a tad debatable\nperhaps, but for the moment we should make sure that psql copes with it.\nUnfortunately, do_connect() failed to: it could pass a NULL pointer to\nstrcmp(), resulting in crashes on most platforms.  This was reported as a\nsecurity issue by ChenQin of Topsec Security Team, but the consensus of\nthe security list is that it's just a garden-variety bug with no security\nimplications.\n\nFor paranoia's sake, I made the keep_password test not trust PQuser or\nPQport either, even though I believe those will never return NULL given\na valid PGconn.\n\nBack-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/64b7079e50cc75fc0e8730793b4a66bfb7388de2"},{"sha":"6823bc282943b44a57cdde3921621f7d83598d83","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix failure to consider failure cases in GetComboCommandId().\n\nFailure to initially palloc the comboCids array, or to realloc it bigger\nwhen needed, left combocid's data structures in an inconsistent state that\nwould cause trouble if the top transaction continues to execute.  Noted\nwhile examining a user complaint about the amount of memory used for this.\n(There's not much we can do about that, but it does point up that repalloc\nfailure has a non-negligible chance of occurring here.)\n\nIn HEAD/9.5, also avoid possible invocation of memcpy() with a null pointer\nin SerializeComboCIDState; cf commit 13bba0227.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/6823bc282943b44a57cdde3921621f7d83598d83"},{"sha":"3e6e98c5a8551e3b90bbc82d5bdad2f574a6f508","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Use \"g\" not \"f\" format in ecpg's PGTYPESnumeric_from_double().\n\nThe previous coding could overrun the provided buffer size for a very large\ninput, or lose precision for a very small input.  Adopt the methodology\nthat's been in use in the equivalent backend code for a long time.\n\nPer private report from Bas van Schaik.  Back-patch to all supported\nbranches.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/3e6e98c5a8551e3b90bbc82d5bdad2f574a6f508"},{"sha":"52774e52dd5832ac3cbee29cb23d24b30fb7eed5","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Make gincostestimate() cope with hypothetical GIN indexes.\n\nWe tried to fetch statistics data from the index metapage, which does not\nwork if the index isn't actually present.  If the index is hypothetical,\ninstead extrapolate some plausible internal statistics based on the index\npage count provided by the index-advisor plugin.\n\nThere was already some code in gincostestimate() to invent internal stats\nin this way, but since it was only meant as a stopgap for pre-9.1 GIN\nindexes that hadn't been vacuumed since upgrading, it was pretty crude.\nIf we want it to support index advisors, we should try a little harder.\nA small amount of testing says that it's better to estimate the entry pages\nas 90% of the index, not 100%.  Also, estimating the number of entries\n(keys) as equal to the heap tuple count could be wildly wrong in either\ndirection.  Instead, let's estimate 100 entries per entry page.\n\nPerhaps someday somebody will want the index advisor to be able to provide\nthese numbers more directly, but for the moment this should serve.\n\nProblem report and initial patch by Julien Rouhaud; modified by me to\ninvent less-bogus internal statistics.  Back-patch to all supported\nbranches, since we've supported index advisors since 9.0.","distinct":true,"url":"https://api.github.com/repos/sunny256/postgres/commits/52774e52dd5832ac3cbee29cb23d24b30fb7eed5"}]}