{"push_id":2916683208,"size":8,"distinct_size":1,"ref":"refs/heads/commitfest/19/1764","head":"6d801a30b0a75f0002dfbb35e1bb35bae3429cc6","before":"92734c5d15c78686e5ad7bd2e19441ace181400b","commits":[{"sha":"aaf10f32a308bc5f53772c773edf3f345f59bb74","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix assorted bugs in pg_get_partition_constraintdef().\n\nIt failed if passed a nonexistent relation OID, or one that was a non-heap\nrelation, because of blindly applying heap_open to a user-supplied OID.\nThis is not OK behavior for a SQL-exposed function; we have a project\npolicy that we should return NULL in such cases.  Moreover, since\npg_get_partition_constraintdef ought now to work on indexes, restricting\nit to heaps is flat wrong anyway.\n\nThe underlying function generate_partition_qual() wasn't on board with\nindexes having partition quals either, nor for that matter with rels\nhaving relispartition set but yet null relpartbound.  (One wonders\nwhether the person who wrote the function comment blocks claiming that\nthese functions allow a missing relpartbound had ever tested it.)\n\nFix by testing relispartition before opening the rel, and by using\nrelation_open not heap_open.  (If any other relkinds ever grow the\nability to have relispartition set, the code will work with them\nautomatically.)  Also, don't reject null relpartbound in\ngenerate_partition_qual.\n\nBack-patch to v11, and all but the null-relpartbound change to v10.\n(It's not really necessary to change generate_partition_qual at all\nin v10, but I thought s/heap_open/relation_open/ would be a good\nidea anyway just to keep the code in sync with later branches.)\n\nPer report from Justin Pryzby.\n\nDiscussion: https://postgr.es/m/20180927200020.GJ776@telsasoft.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/aaf10f32a308bc5f53772c773edf3f345f59bb74"},{"sha":"78ea8b5daab9237fd42d7a8a836c1c451765499f","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix WAL recycling on standbys depending on archive_mode\n\nA restart point or a checkpoint recycling WAL segments treats segments\nmarked with neither \".done\" (archiving is done) or \".ready\" (segment is\nready to be archived) in archive_status the same way for archive_mode\nbeing \"on\" or \"always\".  While for a primary this is fine, a standby\nrunning a restart point with archive_mode = on would try to mark such a\nsegment as ready for archiving, which is something that will never\nhappen except after the standby is promoted.\n\nNote that this problem applies only to WAL segments coming from the\nlocal pg_wal the first time archive recovery is run.  Segments part of a\nself-contained base backup are the most common case where this could\nhappen, however even in this case normally the .done markers would be\nmost likely part of the backup.  Segments recovered from an archive are\nmarked as .ready or .done by the startup process, and segments finished\nstreaming are marked as such by the WAL receiver, so they are handled\nalready.\n\nReported-by: Haruka Takatsuka\nAuthor: Michael Paquier\nDiscussion: https://postgr.es/m/15402-a453c90ed4cf88b2@postgresql.org\nBackpatch-through: 9.5, where archive_mode = always has been added.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/78ea8b5daab9237fd42d7a8a836c1c451765499f"},{"sha":"92a0342a90b38b0b007f079d33286f9aefabfe40","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Correct overflow handling in pgbench.\n\nThis patch attempts, although it's quite possible there are a few\nholes, to properly detect and reported signed integer overflows in\npgbench.\n\nAuthor: Fabien Coelho\nReviewed-By: Andres Freund\nDiscussion: https://postgr.es/m/20171212052943.k2hlckfkeft3eiio@alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/92a0342a90b38b0b007f079d33286f9aefabfe40"},{"sha":"a86bf6057edf7bc344f1ab6ba7824b561ed9068a","author":{"name":"Amit Kapila","email":"4c828daf437d3cc4e3dadceacc8c2924836485c1@postgresql.org"},"message":"Fix assertion failure when updating full_page_writes for checkpointer.\n\nWhen the checkpointer receives a SIGHUP signal to update its configuration,\nit may need to update the shared memory for full_page_writes and need to\nwrite a WAL record for it.  Now, it is quite possible that the XLOG\nmachinery has not been initialized by that time and it will lead to\nassertion failure while doing that.  Fix is to allow the initialization of\nthe XLOG machinery outside critical section.\n\nThis bug has been introduced by the commit 2c03216d83 which added the XLOG\nmachinery initialization in RecoveryInProgress code path.\n\nReported-by: Dilip Kumar\nAuthor: Dilip Kumar\nReviewed-by: Michael Paquier and Amit Kapila\nBackpatch-through: 9.5\nDiscussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a86bf6057edf7bc344f1ab6ba7824b561ed9068a"},{"sha":"f7ab802855200df5529a6e1e7b748d7926acace8","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Remove pqsignal() from libpq's official exports list.\n\nClient applications should get this function, if they need it, from\nlibpgport.\n\nThe fact that it's exported from libpq is a hack left over from before\nwe set up libpgport.  It's never been documented, and there's no good\nreason for non-PG code to be calling it anyway, so hopefully this won't\ncause any problems.  Moreover, with the previous setup it was not real\nclear whether our clients that use the function were getting it from\nlibpgport or libpq, so this might actually prevent problems.\n\nThe reason for changing it now is that in the wake of commit ea53100d5,\nsome linkers won't export the symbol, apparently because it's coming from\na .a library instead of a .o file.  We could get around that by continuing\nto symlink pqsignal.c into libpq as before; but unless somebody complains\nvery hard, I don't want to adopt such a kluge.\n\nDiscussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us\nDiscussion: https://postgr.es/m/E1g5Y8r-0006vs-QA@gemulon.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f7ab802855200df5529a6e1e7b748d7926acace8"},{"sha":"7143b3e82136d2941b3394168940d895a29b4f36","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Build src/common files as a library with -fPIC.\n\nBuild a third version of libpgcommon.a, with -fPIC and -DFRONTEND,\nas commit ea53100d5 did for src/port.  Use that in libpq to avoid\nsymlinking+rebuilding source files retail.\n\nAlso adjust ecpg to use the new src/port and src/common libraries.\n\nArrange to install these libraries, too, to simplify out-of-tree\nbuilds of shared libraries that need any of these modules.\n\nDiscussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us\nDiscussion: https://postgr.es/m/E1g5Y8r-0006vs-QA@gemulon.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7143b3e82136d2941b3394168940d895a29b4f36"},{"sha":"97c6852ff7c54d5b44426ceae9e3215d13157c10","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Tweak MSVC build system to match changes in 7143b3e82.\n\nAlso try to make the comment suggesting that this might be needed\nmore intelligible.\n\nPer buildfarm.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/97c6852ff7c54d5b44426ceae9e3215d13157c10"},{"sha":"6d801a30b0a75f0002dfbb35e1bb35bae3429cc6","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 19/1764] ALTER TABLE on system catalogs\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/19/1764\nPatch(es): https://www.postgresql.org/message-id/a33f9d7f-4afe-a351-3528-cc32b0603845@2ndquadrant.com\nAuthor(s): Peter Eisentraut","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6d801a30b0a75f0002dfbb35e1bb35bae3429cc6"}]}
{"actor":{"display_login":"postgresql-cfbot"}}