{"push_id":1429939654,"size":30,"distinct_size":7,"ref":"refs/heads/decl-part-inh","head":"b197e42ee11b043735e05d0c932bd0f670bf8273","before":"fb91f1fc7e7b13aef79a2dce8332fc42c8a8e394","commits":[{"sha":"4aaddf2f009821e29aea3735e44332ad9ca47aaa","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Fix commit_ts for FrozenXid and BootstrapXid\n\nPreviously, requesting commit timestamp for transactions\nFrozenTransactionId and BootstrapTransactionId resulted in an error.\nBut since those values can validly appear in committed tuples' Xmin,\nthis behavior is unhelpful and error prone: each caller would have to\nspecial-case those values before requesting timestamp data for an Xid.\nWe already have a perfectly good interface for returning \"the Xid you\nrequested is too old for us to have commit TS data for it\", so let's use\nthat instead.\n\nBackpatch to 9.5, where commit timestamps appeared.\n\nAuthor: Craig Ringer\nDiscussion: https://www.postgresql.org/message-id/CAMsr+YFM5Q=+ry3mKvWEqRTxrB0iU3qUSRnS28nz6FJYtBwhJg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4aaddf2f009821e29aea3735e44332ad9ca47aaa"},{"sha":"4cc6a3f1106034187be3a371e61a02915bb93c11","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Check that default_tablespace affects ALTER TABLE ADD UNIQUE/PRIMARY KEY.\n\nSeems like a good thing to test, considering that we nearly broke it\nyesterday.\n\nMichael Paquier","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4cc6a3f1106034187be3a371e61a02915bb93c11"},{"sha":"8afb811088c2a8bfa2b68bd24c05471b8ea4a8ce","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Fix typo in comment\n\nThomas Munro","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/8afb811088c2a8bfa2b68bd24c05471b8ea4a8ce"},{"sha":"4e026b32d4024b03856b4981b26c747b7fef7afb","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Check for pending trigger events on far end when dropping an FK constraint.\n\nWhen dropping a foreign key constraint with ALTER TABLE DROP CONSTRAINT,\nwe refuse the drop if there are any pending trigger events on the named\ntable; this ensures that we won't remove the pg_trigger row that will be\nconsulted by those events.  But we should make the same check for the\nreferenced relation, else we might remove a due-to-be-referenced pg_trigger\nrow for that relation too, resulting in \"could not find trigger NNN\" or\n\"relation NNN has no triggers\" errors at commit.  Per bug #14431 from\nBenjie Gillam.  Back-patch to all supported branches.\n\nReport: <20161124114911.6530.31200@wrigleys.postgresql.org>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4e026b32d4024b03856b4981b26c747b7fef7afb"},{"sha":"ab77a5a4561fad847af4a101a29c922c66449870","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Mark a query's topmost Paths parallel-unsafe if they will have initPlans.\n\nAndreas Seltenreich found another case where we were being too optimistic\nabout allowing a plan to be considered parallelizable despite it containing\ninitPlans.  It seems like the real issue here is that if we know we are\ngoing to tack initPlans onto the topmost Plan node for a subquery, we\nhad better mark that subquery's result Paths as not-parallel-safe.  That\nfixes this problem and allows reversion of a kluge (added in commit\n7b67a0a49 and extended in f24cf960d) to not trust the parallel_safe flag\nat top level.\n\nDiscussion: <874m2w4k5d.fsf@ex.ansel.ydns.eu>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/ab77a5a4561fad847af4a101a29c922c66449870"},{"sha":"dbdfd114f34443f1e4ad16ce2721f9817d3b3d80","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Bring some clarity to the defaults for the xxx_flush_after parameters.\n\nInstead of confusingly stating platform-dependent defaults for these\nparameters in the comments in postgresql.conf.sample (with the main\nentry being a lie on Linux), teach initdb to install the correct\nplatform-dependent value in postgresql.conf, similarly to the way\nwe handle other platform-dependent defaults.  This won't do anything\nfor existing 9.6 installations, but since it's effectively only a\ndocumentation improvement, that seems OK.\n\nSince this requires initdb to have access to the default values,\nmove the #define's for those to pg_config_manual.h; the original\nplacement in bufmgr.h is unworkable because that file can't be\nincluded by frontend programs.\n\nAdjust the default value for wal_writer_flush_after so that it is 1MB\nregardless of XLOG_BLCKSZ, conforming to what is stated in both the\nSGML docs and postgresql.conf.  (We could alternatively make it scale\nwith XLOG_BLCKSZ, but I'm not sure I see the point.)\n\nCopy-edit related SGML documentation.\n\nFabien Coelho and Tom Lane, per a gripe from Tomas Vondra.\n\nDiscussion: <30ebc6e3-8358-09cf-44a8-578252938424@2ndquadrant.com>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/dbdfd114f34443f1e4ad16ce2721f9817d3b3d80"},{"sha":"273270593f42bdbd5422923eb70fbd0fb0f65bf0","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Mark IsPostmasterEnvironment and IsBackgroundWorker as PGDLLIMPORT.\n\nPer request from Craig Ringer.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/273270593f42bdbd5422923eb70fbd0fb0f65bf0"},{"sha":"182db070403fb33566da156a3a77cbcda16583b4","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix test about ignoring extension dependencies during extension scripts.\n\nCommit 08dd23cec introduced an exception to the rule that extension member\nobjects can only be dropped as part of dropping the whole extension,\nintending to allow such drops while running the extension's own creation or\nupdate scripts.  However, the exception was only applied at the outermost\nrecursion level, because it was modeled on a pre-existing check to ignore\ndependencies on objects listed in pendingObjects.  Bug #14434 from Philippe\nBeaudoin shows that this is inadequate: in some cases we can reach an\nextension member object by recursion from another one.  (The bug concerns\nthe serial-sequence case; I'm not sure if there are other cases, but there\nmight well be.)\n\nTo fix, revert 08dd23cec's changes to findDependentObjects() and instead\napply the creating_extension exception regardless of stack level.\n\nHaving seen this example, I'm a bit suspicious that the pendingObjects\nlogic is also wrong and such cases should likewise be allowed at any\nrecursion level.  However, changing that would interact in subtle ways\nwith the recursion logic (at least it would need to be moved to after the\nrecursing-from check).  Given that the code's been like that a long time,\nI'll refrain from touching it without a clear example showing it's wrong.\n\nBack-patch to all active branches.  In HEAD and 9.6, where suitable\ntest infrastructure exists, add a regression test case based on the\nbug report.\n\nReport: <20161125151448.6529.33039@wrigleys.postgresql.org>\nDiscussion: <13224.1480177514@sss.pgh.pa.us>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/182db070403fb33566da156a3a77cbcda16583b4"},{"sha":"c6dbc7b65175f791b8e63a1970ee6b6f68ebec09","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Mention server start requirement for ssl parameters\n\nFix that the documentation for three ssl related parameters did not\nspecify that they can only be changed at server start.\n\nMichael Paquier","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/c6dbc7b65175f791b8e63a1970ee6b6f68ebec09"},{"sha":"dafa0848da11260e9510c699e7060171336cb550","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Code review for early drop of orphaned temp relations in autovacuum.\n\nCommit a734fd5d1 exposed some race conditions that existed previously\nin the autovac code, but were basically harmless because autovac would\nnot try to delete orphaned relations immediately.  Specifically, the test\nfor orphaned-ness was made on a pg_class tuple that might be dead by now,\nallowing autovac to try to remove a table that the owning backend had just\nfinished deleting.  This resulted in a hard crash due to inadequate caution\nabout accessing the table's catalog entries without any lock.  We must take\na relation lock and then recheck whether the table is still present and\nstill looks deletable before we do anything.\n\nAlso, it seemed to me that deleting multiple tables per transaction, and\ntrying to continue after errors, represented unjustifiable complexity.\nWe do not expect this code path to be taken often in the field, nor even\nduring testing, which means that prioritizing performance over correctness\nis a bad tradeoff.  Rip all that out in favor of just starting a new\ntransaction after each successful temp table deletion.  If we're unlucky\nenough to get an error, which shouldn't happen anyway now that we're being\nmore cautious, let the autovacuum worker fail as it normally would.\n\nIn passing, improve the order of operations in the initial scan loop.\nNow that we don't care about whether a temp table is a wraparound hazard,\nthere's no need to perform extract_autovac_opts, get_pgstat_tabentry_relid,\nor relation_needs_vacanalyze for temp tables.\n\nAlso, if GetTempNamespaceBackendId returns InvalidBackendId (indicating\nit doesn't recognize the schema as temp), treat that as meaning it's NOT\nan orphaned temp table, not that it IS one, which is what happened before\nbecause BackendIdGetProc necessarily failed.  The case really shouldn't\ncome up for a table that has RELPERSISTENCE_TEMP, but the consequences\nif it did seem undesirable.  (This might represent a back-patchable bug\nfix; not sure if it's worth the trouble.)\n\nDiscussion: https://postgr.es/m/21299.1480272347@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/dafa0848da11260e9510c699e7060171336cb550"},{"sha":"404e667580fec0ab9a89a38eaa8643ee7227fdb8","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix busted tab-completion pattern for ALTER TABLE t ALTER c DROP ...\n\nEvidently a thinko in commit 9b181b036.\n\nKyotaro Horiguchi","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/404e667580fec0ab9a89a38eaa8643ee7227fdb8"},{"sha":"eb6814168862ef0ff44716467aacdebcef87415a","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Fix get_relation_info name typo'ed in a comment\n\nPlus add a missing comment about this in get_relation_info itself.\n\nAuthor: Amit Langote\nDiscussion: https://postgr.es/m/e46c0569-0449-afa0-e2fe-f3776e4b3fd5@lab.ntt.co.jp","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/eb6814168862ef0ff44716467aacdebcef87415a"},{"sha":"4e20511d5b8ba427730e09be45f9458f667f9c1e","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix estimate_expression_value to constant-fold SQLValueFunction nodes.\n\nOversight in my commit 0bb51aa96.  Noted while poking at a recent\nbug report --- HEAD's estimates for a query using CURRENT_DATE\nwere unexpectedly much worse than 9.6's.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4e20511d5b8ba427730e09be45f9458f667f9c1e"},{"sha":"489a51af12de58e336c7b97e793aed6d11bb13b5","author":{"name":"Stephen Frost","email":"2063edcf0aa2fa8dfb7bba729d6cffa6fed14981@snowman.net"},"message":"Correct psql documentation example\n\nAn example in the psql documentation had an incorrect field name from\nwhat the command actually produced.\n\nPointed out by Fabien COELHO\n\nBack-patch to 9.6 where the example was added.\n\nDiscussion: https://postgr.es/m/alpine.DEB.2.20.1611291349400.19314@lancre","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/489a51af12de58e336c7b97e793aed6d11bb13b5"},{"sha":"b57c8333b55e315927ca65016f1dbc165ef30df9","author":{"name":"Stephen Frost","email":"2063edcf0aa2fa8dfb7bba729d6cffa6fed14981@snowman.net"},"message":"Clarify pg_dump -b documentation\n\nThe documentation around the -b/--blobs option to pg_dump seemed to\nimply that it might be possible to add blobs to a \"schema-only\" dump or\nsimilar.  Clarify that blobs are data and therefore will only be\nincluded in dumps where data is being included, even when -b is used to\nrequest blobs be included.\n\nThe -b option has been around since before 9.2, so back-patch to all\nsupported branches.\n\nDiscussion: https://postgr.es/m/20161119173316.GA13284@tamriel.snowman.net","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/b57c8333b55e315927ca65016f1dbc165ef30df9"},{"sha":"d6c8b34e956864d52780f0db9f8cfe3b2f4411b0","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix incorrect variable type in set_rel_consider_parallel().\n\nfunc_parallel() returns char not Oid.  Harmless, but still wrong.\n\nAmit Langote","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/d6c8b34e956864d52780f0db9f8cfe3b2f4411b0"},{"sha":"4fafa579b0ab411f4cd2f30c57205d9b0ac27340","author":{"name":"Stephen Frost","email":"2063edcf0aa2fa8dfb7bba729d6cffa6fed14981@snowman.net"},"message":"Add --no-blobs option to pg_dump\n\nAdd an option to exclude blobs when running pg_dump.  By default, blobs\nare included but this option can be used to exclude them while keeping\nthe rest of the dump.\n\nCommment updates and regression tests from me.\n\nAuthor: Guillaume Lelarge\nReviewed-by: Amul Sul\nDiscussion: https://postgr.es/m/VisenaEmail.48.49926ea6f91dceb6.15355a48249@tc7-visena","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4fafa579b0ab411f4cd2f30c57205d9b0ac27340"},{"sha":"721f7bd3cbccaf8c07cad2707826b83f84694832","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"libpq: Add target_session_attrs parameter.\n\nCommit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to\nspecify multiple IPs in a connection string, but that's not good\nenough for the case where you have a read-write master and a bunch of\nread-only standbys and want to connect to whichever server is the\nmaster at the current time.  This commit allows that, by making it\npossible to specify target_session_attrs=read-write as a connection\nparameter.\n\nThere was extensive discussion of the best name for the connection\nparameter and its values as well as the best way to distinguish master\nand standbys.  For now, adopt the same solution as JDBC: if the user\nwants a read-write connection, issue 'show transaction_read_only' and\nrejection the connection if the result is 'on'.  In the future, we\ncould add additional values of this new target_session_attrs parameter\nthat issue different queries; or we might have some way of\ndistinguishing the server type without resorting to an SQL query; but\nright now, we have this, and that's (hopefully) a good start.\n\nVictor Wagner and Mithun Cy.  Design review by Álvaro Herrera, Catalin\nIacob, Takayuki Tsunakawa, and Craig Ringer; code review by me.  I\nchanged Mithun's patch to skip all remaining IPs for a host if we\nreject a connection based on this new parameter, rewrote the\ndocumentation, and did some other cosmetic cleanup.\n\nDiscussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/721f7bd3cbccaf8c07cad2707826b83f84694832"},{"sha":"11da83a0e70d32ed0e06a5c948cd8343f8ad5102","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Add uuid to the set of types supported by contrib/btree_gist.\n\nPaul Jungwirth, reviewed and hacked on by Teodor Sigaev, Ildus\nKurbangaliev, Adam Brusselback, Chris Bandy, and myself.\n\nDiscussion: https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com\nDiscussion: https://postgr.es/m/55F6EE82.8080209@sigaev.ru","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/11da83a0e70d32ed0e06a5c948cd8343f8ad5102"},{"sha":"ade49c605f1d8f517497829363f8b83f69c73a60","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Test all contrib-created operator classes with amvalidate.\n\nI'd supposed that people would do this manually when creating new operator\nclasses, but the folly of that was exposed today.  The tests seem fast\nenough that we can just apply them during the normal regression tests.\n\ncontrib/isn fails the checks for lack of complete sets of cross-type\noperators.  That's a nice-to-have policy rather than a functional\nrequirement, so leave it as-is, but insert ORDER BY in the query to\nensure consistent cross-platform output.\n\nDiscussion: https://postgr.es/m/7076.1480446837@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/ade49c605f1d8f517497829363f8b83f69c73a60"}]}
{"actor":{"display_login":"amitlan"}}