{"push_id":2871752676,"size":33,"distinct_size":1,"ref":"refs/heads/commitfest/19/1763","head":"371498f8e651be843a7b4da56a9449062bfc15ea","before":"0f7e9a443cf35f06d8712443e570d0ef062e1352","commits":[{"sha":"2fbdf1b38bc54b297e0f885ca97e0c8f5c922e72","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Simplify partitioned table creation vs. relcache\n\nIn the original code, we were storing the pg_inherits row for a\npartitioned table too early: enough that we had a hack for relcache to\navoid falling flat on its face while reading such a partial entry.  If\nwe finish the pg_class creation first and *then* store the pg_inherits\nentry, we don't need that hack.\n\nAlso recognize that pg_class.relpartbound is not marked NOT NULL and\ntherefore it's entirely possible to read null values, so having only\nAssert() protection isn't enough.  Change those to if/elog tests\ninstead.  This qualifies as a robustness fix, so backpatch to pg11.\n\nIn passing, remove one access that wasn't actually needed, and reword\none message to be like all the others that check for the same thing.\n\nReviewed-by: Amit Langote\nDiscussion: https://postgr.es/m/20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2fbdf1b38bc54b297e0f885ca97e0c8f5c922e72"},{"sha":"ae5205c8a8eff6745fccd39b679ab9ee9c0d13c4","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make argument names of pg_get_object_address consistent, and fix docs.\n\npg_get_object_address and pg_identify_object_as_address are supposed\nto be inverses, but they disagreed as to the names of the arguments\nrepresenting the textual form of an object address.  Moreover, the\ndocumented argument names didn't agree with reality at all, either\nfor these functions or pg_identify_object.\n\nIn HEAD and v11, I think we can get away with renaming the input\narguments of pg_get_object_address to match the outputs of\npg_identify_object_as_address.  In theory that might break queries\nusing named-argument notation to call pg_get_object_address, but\nit seems really unlikely that anybody is doing that, or that they'd\nhave much trouble adjusting if they were.  In older branches, we'll\njust live with the lack of consistency.\n\nAside from fixing the documentation of these functions to match reality,\nI couldn't resist the temptation to do some copy-editing.\n\nPer complaint from Jean-Pierre Pelletier.  Back-patch to 9.5 where these\nfunctions were introduced.  (Before v11, this is a documentation change\nonly.)\n\nDiscussion: https://postgr.es/m/CANGqjDnWH8wsTY_GzDUxbt4i=y-85SJreZin4Hm8uOqv1vzRQA@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ae5205c8a8eff6745fccd39b679ab9ee9c0d13c4"},{"sha":"54b01b9293830d82d5b6c827771c683ff52ffb0b","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Remove no-longer-used variable.\n\nOversight in 2fbdf1b38.  Per buildfarm.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/54b01b9293830d82d5b6c827771c683ff52ffb0b"},{"sha":"be54b3777ff189e79661d8746d3f25b0564393d2","author":{"name":"Andrew Gierth","email":"f5e6496b0ff21826a604b558aceee3773835e92d@postgresql.org"},"message":"Allow extensions to install built as well as unbuilt headers.\n\nCommit df163230b overlooked the case that an out-of-tree extension\nmight need to build its header files (e.g. via ./configure). If it is\nalso doing a VPATH build, the HEADERS_* rules in the original commit\nwould then fail to find the files, since they would be looking only\nunder $(srcdir) and not in the build directory.\n\nFix by adding HEADERS_built and HEADERS_built_$(MODULE) which behave\nlike DATA_built in that they look in the build dir rather than the\nsource dir (and also make the files dependencies of the \"all\" target).\n\nNo Windows support appears to be needed for this, since it is only\nrelevant to out-of-tree builds (no support exists in Mkvcbuild.pm to\nbuild extension header files in any case).","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/be54b3777ff189e79661d8746d3f25b0564393d2"},{"sha":"ac27c74def5d8544530b13d5901308a342f072ac","author":{"name":"Amit Kapila","email":"4c828daf437d3cc4e3dadceacc8c2924836485c1@postgresql.org"},"message":"Fix the overrun in hash index metapage for smaller block sizes.\n\nThe commit 620b49a1 changed the value of HASH_MAX_BITMAPS with the intent\nto allow many non-unique values in hash indexes without worrying to reach\nthe limit of the number of overflow pages.  At that time, this didn't\noccur to us that it can overrun the block for smaller block sizes.\n\nChoose the value of HASH_MAX_BITMAPS based on BLCKSZ such that it gives\nthe same answer as now for the cases where the overrun doesn't occur, and\nsome other sufficiently-value for the cases where an overrun currently\ndoes occur.  This allows us not to change the behavior in any case that\ncurrently works, so there's really no reason for a HASH_VERSION bump.\n\nAuthor: Dilip Kumar\nReviewed-by: Amit Kapila\nBackpatch-through: 10\nDiscussion: https://postgr.es/m/CAA4eK1LtF4VmU4mx_+i72ff1MdNZ8XaJMGkt2HV8+uSWcn8t4A@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ac27c74def5d8544530b13d5901308a342f072ac"},{"sha":"842cb9fa62fc99598086166bdeec9d6ae6e3c50f","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Refactor dlopen() support\n\nNowadays, all platforms except Windows and older HP-UX have standard\ndlopen() support.  So having a separate implementation per platform\nunder src/backend/port/dynloader/ is a bit excessive.  Instead, treat\ndlopen() like other library functions that happen to be missing\nsometimes and put a replacement implementation under src/port/.\n\nDiscussion: https://www.postgresql.org/message-id/flat/e11a49cb-570a-60b7-707d-7084c8de0e61%402ndquadrant.com#54e735ae37476a121abb4e33c2549b03","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/842cb9fa62fc99598086166bdeec9d6ae6e3c50f"},{"sha":"a5322ca10fa16bed01e3e3d6c49c0f49c68b5593","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make contrib/unaccent's unaccent() function work when not in search path.\n\nSince the fixes for CVE-2018-1058, we've advised people to schema-qualify\nfunction references in order to fix failures in code that executes under\na minimal search_path setting.  However, that's insufficient to make the\nsingle-argument form of unaccent() work, because it looks up the \"unaccent\"\ntext search dictionary using the search path.\n\nThe most expedient answer seems to be to remove the search_path dependency\nby making it look in the same schema that the unaccent() function itself\nis declared in.  This will definitely work for the normal usage of this\nfunction with the unaccent dictionary provided by the extension.\nIt's barely possible that there are people who were relying on the\nsearch-path-dependent behavior to select other dictionaries with the same\nname; but if there are any such people at all, they can still get that\nbehavior by writing unaccent('unaccent', ...), or possibly\nunaccent('unaccent'::text::regdictionary, ...) if the lookup has to be\npostponed to runtime.\n\nPer complaint from Gunnlaugur Thor Briem.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/CAPs+M8LCex6d=DeneofdsoJVijaG59m9V0ggbb3pOH7hZO4+cQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a5322ca10fa16bed01e3e3d6c49c0f49c68b5593"},{"sha":"75f7855369ec56d4a8e7d6eae98aff1182b85cac","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix inconsistent argument naming.\n\nTypo in commit 842cb9fa6.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/75f7855369ec56d4a8e7d6eae98aff1182b85cac"},{"sha":"98afa68d935215e8ab2c7de7fb45972a03e3da26","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Use C99 designated initializers for some structs\n\nThese are just a few particularly egregious cases that were hard to read\nand write, and error prone because of many similar adjacent types.\n\nDiscussion: https://www.postgresql.org/message-id/flat/4c9f01be-9245-2148-b569-61a8562ef190%402ndquadrant.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/98afa68d935215e8ab2c7de7fb45972a03e3da26"},{"sha":"1fea1e325492b10f645809204631426bb6abbe6e","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"libpq: Change \"options\" dispchar to normal\n\nlibpq connection options as returned by PQconndefaults() have a\n\"dispchar\" field that determines (among other things) whether an option\nis a \"debug\" option, which shouldn't be shown by default to clients.\npostgres_fdw makes use of that to control which connection options to\naccept from a foreign server configuration.\n\nCuriously, the \"options\" option, which allows passing configuration\nsettings to the backend server, was listed as a debug option, which\nprevented it from being used by postgres_fdw.  Maybe it was once meant\nfor debugging, but it's clearly in general use nowadays.\n\nSo change the dispchar for it to be the normal non-debug case.  Also\nremove the \"debug\" reference from its label field.\n\nReported-by: Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1fea1e325492b10f645809204631426bb6abbe6e"},{"sha":"7b6b167fa3bd2f968ad885ca7b024be4122a85f1","author":{"name":"Andrew Gierth","email":"f5e6496b0ff21826a604b558aceee3773835e92d@postgresql.org"},"message":"Refactor installation of extension headers.\n\nCommit be54b3777 failed on gmake 3.80 due to a chained conditional,\nwhich on closer examination could be removed entirely with some\nrefactoring elsewhere for a net simplification and more robustness\nagainst empty expansions. Along the way, add some more comments.\n\nAlso make explicit in the documentation and comments that built\nheaders are not removed by 'make clean', since we don't typically want\nthat for headers generated by a separate ./configure step, and it's\nmuch easier to add your own 'distclean' rule or use EXTRA_CLEAN than\nto try and override a deletion rule in pgxs.mk.\n\nPer buildfarm member prariedog and comments by Michael Paquier, though\nall the actual changes are my fault.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7b6b167fa3bd2f968ad885ca7b024be4122a85f1"},{"sha":"8582b4d044b05d3fe4bcdf6e039fde8e753934ae","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Improve handling of corrupted two-phase state files at recovery\n\nWhen a corrupted two-phase state file is found by WAL replay, be it for\ncrash recovery or archive recovery, then the file is simply skipped and\na WARNING is logged to the user, causing the transaction to be silently\nlost.  Facing an on-disk WAL file which is corrupted is as likely to\nhappen as what is stored in WAL records, but WAL records are already\nable to fail hard if there is a CRC mismatch.  On-disk two-phase state\nfiles, on the contrary, are simply ignored if corrupted.  Note that when\nrestoring the initial two-phase data state at recovery, files newer than\nthe horizon XID are discarded hence no files present in pg_twophase/\nshould be torned and have been made durable by a previous checkpoint, so\nrecovery should never see any corrupted two-phase state file by design.\n\nThe situation got better since 978b2f6 which has added two-phase state\ninformation directly in WAL instead of using on-disk files, so the risk\nis limited to two-phase transactions which live across at least one\ncheckpoint for long periods.  Backups having legit two-phase state files\non-disk could also lose silently transactions when restored if things\nget corrupted.\n\nThis behavior exists since two-phase commit has been introduced, no\nback-patch is done for now per the lack of complaints about this\nproblem.\n\nAuthor: Michael Paquier\nDiscussion: https://postgr.es/m/20180709050309.GM1467@paquier.xyz","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/8582b4d044b05d3fe4bcdf6e039fde8e753934ae"},{"sha":"f868a8143a98c4172e3faaf415d9352179d5760b","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix longstanding recursion hazard in sinval message processing.\n\nLockRelationOid and sibling routines supposed that, if our session already\nholds the lock they were asked to acquire, they could skip calling\nAcceptInvalidationMessages on the grounds that we must have already read\nany remote sinval messages issued against the relation being locked.\nThis is normally true, but there's a critical special case where it's not:\nprocessing inside AcceptInvalidationMessages might attempt to access system\nrelations, resulting in a recursive call to acquire a relation lock.\n\nHence, if the outer call had acquired that same system catalog lock, we'd\nfall through, despite the possibility that there's an as-yet-unread sinval\nmessage for that system catalog.  This could, for example, result in\nfailure to access a system catalog or index that had just been processed\nby VACUUM FULL.  This is the explanation for buildfarm failures we've been\nseeing intermittently for the past three months.  The bug is far older\nthan that, but commits a54e1f158 et al added a new recursion case within\nAcceptInvalidationMessages that is apparently easier to hit than any\nprevious case.\n\nTo fix this, we must not skip calling AcceptInvalidationMessages until\nwe have *finished* a call to it since acquiring a relation lock, not\nmerely acquired the lock.  (There's already adequate logic inside\nAcceptInvalidationMessages to deal with being called recursively.)\nFortunately, we can implement that at trivial cost, by adding a flag\nto LOCALLOCK hashtable entries that tracks whether we know we have\ncompleted such a call.\n\nThere is an API hazard added by this patch for external callers of\nLockAcquire: if anything is testing for LOCKACQUIRE_ALREADY_HELD,\nit might be fooled by the new return code LOCKACQUIRE_ALREADY_CLEAR\ninto thinking the lock wasn't already held.  This should be a fail-soft\ncondition, though, unless something very bizarre is being done in\nresponse to the test.\n\nAlso, I added an additional output argument to LockAcquireExtended,\nassuming that that probably isn't called by any outside code given\nthe very limited usefulness of its additional functionality.\n\nBack-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f868a8143a98c4172e3faaf415d9352179d5760b"},{"sha":"f510412df3510e244fb3f9570ba5d2b4d27e773a","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.\n\nIt's somewhat surprising that we got away with this before.  (Actually,\nsince nobody tests this routinely AFAIK, it might've been broken for\nawhile.  But it's definitely broken in the wake of commit f868a8143.)\nIt seems sufficient to limit the forced recursion to a small number\nof levels.\n\nBack-patch to all supported branches, like the preceding patch.\n\nDiscussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f510412df3510e244fb3f9570ba5d2b4d27e773a"},{"sha":"361844fe561f6898d90a10382705ad968929a4b2","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Save/restore SPI's global variables in SPI_connect() and SPI_finish().\n\nThis patch removes two sources of interference between nominally\nindependent functions when one SPI-using function calls another,\nperhaps without knowing that it does so.\n\nChapman Flack pointed out that xml.c's query_to_xml_internal() expects\nSPI_tuptable and SPI_processed to stay valid across datatype output\nfunction calls; but it's possible that such a call could involve\nre-entrant use of SPI.  It seems likely that there are similar hazards\nelsewhere, if not in the core code then in third-party SPI users.\nPreviously SPI_finish() reset SPI's API globals to zeroes/nulls, which\nwould typically make for a crash in such a situation.  Restoring them\nto the values they had at SPI_connect() seems like a considerably more\nuseful behavior, and it still meets the design goal of not leaving any\ndangling pointers to tuple tables of the function being exited.\n\nAlso, cause SPI_connect() to reset these variables to zeroes/nulls after\nsaving them.  This prevents interference in the opposite direction: it's\npossible that a SPI-using function that's only ever been tested standalone\ncontains assumptions that these variables start out as zeroes.  That was\nthe case as long as you were the outermost SPI user, but not so much for\nan inner user.  Now it's consistent.\n\nReport and fix suggestion by Chapman Flack, actual patch by me.\nBack-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/9fa25bef-2e4f-1c32-22a4-3ad0723c4a17@anastigmatix.net","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/361844fe561f6898d90a10382705ad968929a4b2"},{"sha":"9226a3b89b004b3472d963442856206f0c249a53","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Remove duplicated words split across lines in comments\n\nThis has been detected using some interesting tricks with sed, and the\nmethod used is mentioned in details in the discussion below.\n\nAuthor: Justin Pryzby\nDiscussion: https://postgr.es/m/20180908013109.GB15350@telsasoft.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9226a3b89b004b3472d963442856206f0c249a53"},{"sha":"f47f3148011f1cb5dc34396382fc2f434844d247","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Minor cleanup/future-proofing for pg_saslprep().\n\nEnsure that pg_saslprep() initializes its output argument to NULL in\nall failure paths, and then remove the redundant initialization that\nsome (not all) of its callers did.  This does not fix any live bug,\nbut it reduces the odds of future bugs of omission.\n\nAlso add a comment about why the existing failure-path coding is\nadequate.\n\nBack-patch so as to keep the function's API consistent across branches,\nagain to forestall future bug introduction.\n\nPatch by me, reviewed by Michael Paquier\n\nDiscussion: https://postgr.es/m/16558.1536407783@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f47f3148011f1cb5dc34396382fc2f434844d247"},{"sha":"076a3c2112b127b3b36346dbc64659f9a165f60f","author":{"name":"Noah Misch","email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com"},"message":"Fix logical subscriber wait in test.\n\nBuildfarm members sungazer and tern revealed this deficit.  Back-patch\nto v10, like commit 4f10e7ea7b2231f453bb18b6e710ac333eaf121b, which\nintroduced the test.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/076a3c2112b127b3b36346dbc64659f9a165f60f"},{"sha":"c85ad9cc63e1487758f3969e20826cac0e944a27","author":{"name":"Noah Misch","email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com"},"message":"Allow ENOENT in check_mode_recursive().\n\nBuildfarm member tern failed src/bin/pg_ctl/t/001_start_stop.pl when a\ncheck_mode_recursive() call overlapped a server's startup-time deletion\nof pg_stat/global.stat.  Just warn.  Also, include errno in the message.\nBack-patch to v11, where check_mode_recursive() first appeared.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c85ad9cc63e1487758f3969e20826cac0e944a27"},{"sha":"ed0cdf0e05134d1084b01bf8a77e9e1dc5081f91","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Install a check for mis-linking of src/port and src/common functions.\n\nOn ELF-based platforms (and maybe others?) it's possible for a shared\nlibrary, when dynamically loaded into the backend, to call the backend\nversions of src/port and src/common functions rather than the frontend\nversions that are actually linked into the shlib.  This is definitely\nnot what we want, because the frontend versions often behave slightly\ndifferently.  Up to now it's been \"slight\" enough that nobody noticed;\nbut with the addition of SCRAM support functions in src/common, we're\nobserving crashes due to the difference between palloc and malloc\nmemory allocation rules, as reported in bug #15367 from Jeremy Evans.\n\nThe purpose of this patch is to create a direct test for this type of\nmis-linking, so that we know whether any given platform requires extra\nmeasures to prevent using the wrong functions.  If the test fails, it\nwill lead to connection failures in the contrib/postgres_fdw regression\ntest.  At the moment, *BSD platforms using ELF format are known to have\nthe problem and can be expected to fail; but we need to know whether\nanything else does, and we need a reliable ongoing check for future\nplatforms.\n\nActually fixing the problem will be the subject of later commit(s).\n\nDiscussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ed0cdf0e05134d1084b01bf8a77e9e1dc5081f91"}]}
{"actor":{"display_login":"postgresql-cfbot"}}