{"push_id":1988012719,"size":68,"distinct_size":4,"ref":"refs/heads/feature/create-function-depends-on","head":"867b31da132c83690ededefce5c7e6c2e42ded01","before":"62a661b33b41dd85d3be8f69000da4918a132339","commits":[{"sha":"00f6d5c2c3ae2f6d198e41800e5edcf0150d485b","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"doc: Avoid sidebar element\n\nThe formatting of the sidebar element didn't carry over to the new tool\nchain.  Instead of inventing a whole new way of dealing with it, just\nconvert the one use to a \"note\".","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/00f6d5c2c3ae2f6d198e41800e5edcf0150d485b"},{"sha":"7df2c1f8daeb361133ac8bdeaf59ceb0484e315a","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Force rescanning of parallel-aware scan nodes below a Gather[Merge].\n\nThe ExecReScan machinery contains various optimizations for postponing\nor skipping rescans of plan subtrees; for example a HashAgg node may\nconclude that it can re-use the table it built before, instead of\nre-reading its input subtree.  But that is wrong if the input contains\na parallel-aware table scan node, since the portion of the table scanned\nby the leader process is likely to vary from one rescan to the next.\nThis explains the timing-dependent buildfarm failures we saw after\ncommit a2b70c89c.\n\nThe established mechanism for showing that a plan node's output is\npotentially variable is to mark it as depending on some runtime Param.\nHence, to fix this, invent a dummy Param (one that has a PARAM_EXEC\nparameter number, but carries no actual value) associated with each Gather\nor GatherMerge node, mark parallel-aware nodes below that node as dependent\non that Param, and arrange for ExecReScanGather[Merge] to flag that Param\nas changed whenever the Gather[Merge] node is rescanned.\n\nThis solution breaks an undocumented assumption made by the parallel\nexecutor logic, namely that all rescans of nodes below a Gather[Merge]\nwill happen synchronously during the ReScan of the top node itself.\nBut that's fundamentally contrary to the design of the ExecReScan code,\nand so was doomed to fail someday anyway (even if you want to argue\nthat the bug being fixed here wasn't a failure of that assumption).\nA follow-on patch will address that issue.  In the meantime, the worst\nthat's expected to happen is that given very bad timing luck, the leader\nmight have to do all the work during a rescan, because workers think\nthey have nothing to do, if they are able to start up before the eventual\nReScan of the leader's parallel-aware table scan node has reset the\nshared scan state.\n\nAlthough this problem exists in 9.6, there does not seem to be any way\nfor it to manifest there.  Without GatherMerge, it seems that a plan tree\nthat has a rescan-short-circuiting node below Gather will always also\nhave one above it that will short-circuit in the same cases, preventing\nthe Gather from being rescanned.  Hence we won't take the risk of\nback-patching this change into 9.6.  But v10 needs it.\n\nDiscussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/7df2c1f8daeb361133ac8bdeaf59ceb0484e315a"},{"sha":"6c2c5bea3cec4c874d1ee225bb6e222055c03d75","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Restore test case from a2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b.\n\nRevert the reversion commits a20aac890 and 9b644745c.  In the wake of\ncommit 7df2c1f8d, we should get stable buildfarm results from this test;\nif not, I'd like to know sooner not later.\n\nDiscussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/6c2c5bea3cec4c874d1ee225bb6e222055c03d75"},{"sha":"41b0dd987d44089dc48e9c70024277e253b396b7","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Separate reinitialization of shared parallel-scan state from ExecReScan.\n\nPreviously, the parallel executor logic did reinitialization of shared\nstate within the ExecReScan code for parallel-aware scan nodes.  This is\nproblematic, because it means that the ExecReScan call has to occur\nsynchronously (ie, during the parent Gather node's ReScan call).  That is\nswimming very much against the tide so far as the ExecReScan machinery is\nconcerned; the fact that it works at all today depends on a lot of fragile\nassumptions, such as that no plan node between Gather and a parallel-aware\nscan node is parameterized.  Another objection is that because ExecReScan\nmight be called in workers as well as the leader, hacky extra tests are\nneeded in some places to prevent unwanted shared-state resets.\n\nHence, let's separate this code into two functions, a ReInitializeDSM\ncall and the ReScan call proper.  ReInitializeDSM is called only in\nthe leader and is guaranteed to run before we start new workers.\nReScan is returned to its traditional function of resetting only local\nstate, which means that ExecReScan's usual habits of delaying or\neliminating child rescan calls are safe again.\n\nAs with the preceding commit 7df2c1f8d, it doesn't seem to be necessary\nto make these changes in 9.6, which is a good thing because the FDW and\nCustomScan APIs are impacted.\n\nDiscussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/41b0dd987d44089dc48e9c70024277e253b396b7"},{"sha":"04e9678614ec64ad9043174ac99a25b1dc45233a","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Code review for nodeGatherMerge.c.\n\nComment the fields of GatherMergeState, and organize them a bit more\nsensibly.  Comment GMReaderTupleBuffer more usefully too.  Improve\nassorted other comments that were obsolete or just not very good English.\n\nGet rid of the use of a GMReaderTupleBuffer for the leader process;\nthat was confusing, since only the \"done\" field was used, and that\nin a way redundant with need_to_scan_locally.\n\nIn gather_merge_init, avoid calling load_tuple_array for\nalready-known-exhausted workers.  I'm not sure if there's a live bug there,\nbut the case is unlikely to be well tested due to timing considerations.\n\nRemove some useless code, such as duplicating the tts_isempty test done by\nTupIsNull.\n\nRemove useless initialization of ps.qual, replacing that with an assertion\nthat we have no qual to check.  (If we did, the code would fail to check\nit.)\n\nAvoid applying heap_copytuple to a null tuple.  While that fails to crash,\nit's confusing and it makes the code less legible not more so IMO.\n\nPropagate a couple of these changes into nodeGather.c, as well.\n\nBack-patch to v10, partly because of the possibility that the\ngather_merge_init change is fixing a live bug, but mostly to keep\nthe branches in sync to ease future bug fixes.","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/04e9678614ec64ad9043174ac99a25b1dc45233a"},{"sha":"b5c75feca7ffb2667c42b86286e262d6cb709b76","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Remove to pre-8.2 coding convention for PG_MODULE_MAGIC\n\nPG_MODULE_MAGIC has been around since 8.2, with 8.1 long since in EOL,\nso remove the mention of #ifdef guards for compiling against pre-8.2\nsources from the documentation.\n\nAuthor: Daniel Gustafsson <daniel@yesql.se>","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/b5c75feca7ffb2667c42b86286e262d6cb709b76"},{"sha":"4b1dd62a257a469f92fef4f4cce37beab6c0b98b","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Improve code coverage of select_parallel test.\n\nMake sure that rescans of parallel indexscans are tested.\nPer code coverage report.","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/4b1dd62a257a469f92fef4f4cce37beab6c0b98b"},{"sha":"6708e447efb5046c95bdcf900b6da97f56f97ae8","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Clean up shm_mq cleanup.\n\nThe logic around shm_mq_detach was a few bricks shy of a load, because\n(contrary to the comments for shm_mq_attach) all it did was update the\nshared shm_mq state.  That left us leaking a bit of process-local\nmemory, but much worse, the on_dsm_detach callback for shm_mq_detach\nwas still armed.  That means that whenever we ultimately detach from\nthe DSM segment, we'd run shm_mq_detach again for already-detached,\npossibly long-dead queues.  This accidentally fails to fail today,\nbecause we only ever re-use a shm_mq's memory for another shm_mq, and\nmultiple detach attempts on the last such shm_mq are fairly harmless.\nBut it's gonna bite us someday, so let's clean it up.\n\nTo do that, change shm_mq_detach's API so it takes a shm_mq_handle\nnot the underlying shm_mq.  This makes the callers simpler in most\ncases anyway.  Also fix a few places in parallel.c that were just\npfree'ing the handle structs rather than doing proper cleanup.\n\nBack-patch to v10 because of the risk that the revenant shm_mq_detach\ncallbacks would cause a live bug sometime.  Since this is an API\nchange, it's too late to do it in 9.6.  (We could make a variant\npatch that preserves API, but I'm not excited enough to do that.)\n\nDiscussion: https://postgr.es/m/8670.1504192177@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/6708e447efb5046c95bdcf900b6da97f56f97ae8"},{"sha":"30833ba154e0c1106d61e3270242dc5999a3e4f3","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Expand partitioned tables in PartDesc order.\n\nPreviously, we expanded the inheritance hierarchy in the order in\nwhich find_all_inheritors had locked the tables, but that turns out\nto block quite a bit of useful optimization.  For example, a\npartition-wise join can't count on two tables with matching bounds\nto get expanded in the same order.\n\nWhere possible, this change results in expanding partitioned tables in\n*bound* order.  Bound order isn't well-defined for a list-partitioned\ntable with a null-accepting partition or for a list-partitioned table\nwhere the bounds for a single partition are interleaved with other\npartitions.  However, when expansion in bound order is possible, it\nopens up further opportunities for optimization, such as\nstrength-reducing MergeAppend to Append when the expansion order\nmatches the desired sort order.\n\nPatch by me, with cosmetic revisions by Ashutosh Bapat.\n\nDiscussion: http://postgr.es/m/CA+TgmoZrKj7kEzcMSum3aXV4eyvvbh9WD=c6m=002WMheDyE3A@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/30833ba154e0c1106d61e3270242dc5999a3e4f3"},{"sha":"2d44c58c79aeef2d376be0141057afbb9ec6b5bc","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Avoid memory leaks when a GatherMerge node is rescanned.\n\nRescanning a GatherMerge led to leaking some memory in the executor's\nquery-lifespan context, because most of the node's working data structures\nwere simply abandoned and rebuilt from scratch.  In practice, this might\nnever amount to much, given the cost of relaunching worker processes ---\nbut it's still pretty messy, so let's fix it.\n\nWe can rearrange things so that the tuple arrays are simply cleared and\nreused, and we don't need to rebuild the TupleTableSlots either, just\nclear them.  One small complication is that because we might get a\ndifferent number of workers on each iteration, we can't keep the old\nconvention that the leader's gm_slots[] entry is the last one; the leader\nmight clobber a TupleTableSlot that we need for a worker in a future\niteration.  Hence, adjust the logic so that the leader has slot 0 always,\nwhile the active workers have slots 1..n.\n\nBack-patch to v10 to keep all the existing versions of nodeGatherMerge.c\nin sync --- because of the renumbering of the slots, there would otherwise\nbe a very large risk that any future backpatches in this module would\nintroduce bugs.\n\nDiscussion: https://postgr.es/m/8670.1504192177@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/2d44c58c79aeef2d376be0141057afbb9ec6b5bc"},{"sha":"81c5e46c490e2426db243eada186995da5bb0ba7","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Introduce 64-bit hash functions with a 64-bit seed.\n\nThis will be useful for hash partitioning, which needs a way to seed\nthe hash functions to avoid problems such as a hash index on a hash\npartitioned table clumping all values into a small portion of the\nbucket space; it's also useful for anything that wants a 64-bit hash\nvalue rather than a 32-bit hash value.\n\nJust in case somebody wants a 64-bit hash value that is compatible\nwith the existing 32-bit hash values, make the low 32-bits of the\n64-bit hash value match the 32-bit hash value when the seed is 0.\n\nRobert Haas and Amul Sul\n\nDiscussion: http://postgr.es/m/CA+Tgmoafx2yoJuhCQQOL5CocEi-w_uG4S2xT0EtgiJnPGcHW3g@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/81c5e46c490e2426db243eada186995da5bb0ba7"},{"sha":"0d9506d125beef18247a5e38a219d3b23e2d312e","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Try to repair poorly-considered code in previous commit.","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/0d9506d125beef18247a5e38a219d3b23e2d312e"},{"sha":"7b69b6ceb8047979ddf82af12ec1de143da62263","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix assorted carelessness about Datum vs. int64 vs. uint64\n\nBugs introduced by commit 81c5e46c490e2426db243eada186995da5bb0ba7","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/7b69b6ceb8047979ddf82af12ec1de143da62263"},{"sha":"abe85ef1d00187a42e7a757ea0413bc4965a4525","author":{"name":"Simon Riggs","email":"3a69a7dd305e9c7705028afae27095688d25197a@2ndQuadrant.com"},"message":"Add note about diskspace usage of pg_commit_ts\n\nAuthor: Thomas Munro","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/abe85ef1d00187a42e7a757ea0413bc4965a4525"},{"sha":"be7161566db247fd519e1a888ea8cd36b3c72088","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Add a WAIT option to DROP_REPLICATION_SLOT\n\nCommit 9915de6c1cb2 changed the default behavior of\nDROP_REPLICATION_SLOT so that it would wait until any session holding\nthe slot active would release it, instead of raising an error.  But\nusers are already depending on the original behavior, so revert to it by\ndefault and add a WAIT option to invoke the new behavior.\n\nPer complaint from Simone Gotti, in\nDiscussion: https://postgr.es/m/CAEvsy6Wgdf90O6pUvg2wSVXL2omH5OPC-38OD4Zzgk-FXavj3Q@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/be7161566db247fd519e1a888ea8cd36b3c72088"},{"sha":"4f27c674fd9fb5ba1f2952e2db53886bb5954e8b","author":{"name":"Simon Riggs","email":"3a69a7dd305e9c7705028afae27095688d25197a@2ndQuadrant.com"},"message":"Avoid race condition in logical replication test\n\nWait for slot to become inactive before continuing.\n\nAuthor: Petr Jelinek","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/4f27c674fd9fb5ba1f2952e2db53886bb5954e8b"},{"sha":"a6979c3a68e2caa6696021f7a15278a99e7409a1","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Restore behavior for replication origin drop\n\nDo for replication origins what the previous commit did for replication\nslots: restore the original behavior of replication origin drop to raise\nan error rather than blocking, because users might be depending on the\noriginal behavior.  Maintain the blocking behavior when invoked\ninternally from logical replication subscription handling.\n\nDiscussion: https://postgr.es/m/20170830133922.tlpo3lgfejm4n2cs@alvherre.pgsql","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/a6979c3a68e2caa6696021f7a15278a99e7409a1"},{"sha":"89c59b742a7f89eb598a25b70aaa3ab97381f67d","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Fix two-phase commit test for recovery mode\n\nThe original code had a race condition because it never ensured the\nstandby was caught up before proceeding; add a wait similar to every\nother place that does this.\n\nAuthor: Michaël Paquier\nDiscussion: https://postgr.es/m/CAB7nPqTm9p+LCm1mVJYvgpwagRK+uibT-pKq0O2-paOWxT62jw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/89c59b742a7f89eb598a25b70aaa3ab97381f67d"},{"sha":"baaf272ac908ea27c09076e34f62c45fa7d1e448","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Use group updates when setting transaction status in clog.\n\nCommit 0e141c0fbb211bdd23783afa731e3eef95c9ad7a introduced a mechanism\nto reduce contention on ProcArrayLock by having a single process clear\nXIDs in the procArray on behalf of multiple processes, reducing the\nneed to hand the lock around.  A previous attempt to introduce a similar\nmechanism for CLogControlLock in ccce90b398673d55b0387b3de66639b1b30d451b\ncrashed and burned, but the design problem which resulted in those\nfailures is believed to have been corrected in this version.\n\nAmit Kapila, with some cosmetic changes by me.  See the previous commit\nmessage for additional credits.\n\nDiscussion: http://postgr.es/m/CAA4eK1KudxzgWhuywY_X=yeSAhJMT4DwCjroV5Ay60xaeB2Eew@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/baaf272ac908ea27c09076e34f62c45fa7d1e448"},{"sha":"2f5ada2710d6e5a668d6d6b27f93ac545a01bafd","author":{"name":"Simon Riggs","email":"3a69a7dd305e9c7705028afae27095688d25197a@2ndQuadrant.com"},"message":"Provisional list of Major Features","distinct":false,"url":"https://api.github.com/repos/erthalion/postgres/commits/2f5ada2710d6e5a668d6d6b27f93ac545a01bafd"}]}
{"actor":{"display_login":"erthalion"}}