== PostgreSQL Weekly News - December 16, 2018 ==
От | David Fetter |
---|---|
Тема | == PostgreSQL Weekly News - December 16, 2018 == |
Дата | |
Msg-id | 20181216213705.GA20160@fetter.org обсуждение исходный текст |
Список | pgsql-announce |
== PostgreSQL Weekly News - December 16, 2018 == The German-speaking PostgreSQL Conference 2019 will take place on May 10, 2019 in Leipzig. The CfP is open until February 26, 2019 at http://2019.pgconf.de/cfp http://2019.pgconf.de/ == PostgreSQL Product News == pgCluu 2.9, a Perl program to audit PostgreSQL performance, released. http://pgcluu.darold.net/ dbForge Studio for PostgreSQL released. https://blog.devart.com/whats-new-in-dbforge-studio-for-postgresql-20.html == PostgreSQL Jobs for December == http://archives.postgresql.org/pgsql-jobs/2018-12/ == PostgreSQL Local == FOSDEM PGDay 2019, a one day conference held before the main FOSDEM event will be held in Brussels, Belgium, on Feb 1st, 2019. https://2019.fosdempgday.org/ Prague PostgreSQL Developer Day 2019 (P2D2 2019) is a two-day conference that will be held on February 13-14, 2019 in Prague, Czech Republic. The CfP is open until January 4, 2018 at https://p2d2.cz/callforpapers http://www.p2d2.cz/ PGConf India 2019 will be on February 13-15, 2019 in Bengaluru, Karnataka. http://pgconf.in/ pgDay Paris 2019 will be held in Paris, France on March 12, 2019 at 199bis rue Saint-Martin. http://2019.pgday.paris/ PGConf APAC 2019 will be held in Singapore March 19-21, 2019. http://2019.pgconfapac.org/ PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy. Both the CfP https://2019.pgday.it/en/blog/cfp and the Call for Workshops https://2019.pgday.it/en/blog/cfw are openuntil January 15, 2019. https://2019.pgday.it/en/ PGCon 2019 will take place in Ottawa on May 28-31, 2019. The CfP is open through January 19, 2019 at http://www.pgcon.org/2019/papers.php https://www.pgcon.org/2018/schedule/ Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019. The CfP is open January 17, 2019 through April 18, 2019, and registration will open January 17, 2019. http://www.pgday.ch/2019/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.org. == PostgreSQL Weekly News - December 16, 2018 == pgCluu 2.9, a Perl program to audit PostgreSQL performance, released. http://pgcluu.darold.net/ dbForge Studio for PostgreSQL released. https://blog.devart.com/whats-new-in-dbforge-studio-for-postgresql-20.html The German-speaking PostgreSQL Conference 2019 will take place on May 10, 2019 in Leipzig. The CfP is open until February 26, 2019 at http://2019.pgconf.de/cfp http://2019.pgconf.de/ == PostgreSQL Product News == == PostgreSQL Jobs for December == http://archives.postgresql.org/pgsql-jobs/2018-12/ == PostgreSQL Local == FOSDEM PGDay 2019, a one day conference held before the main FOSDEM event will be held in Brussels, Belgium, on Feb 1st, 2019. https://2019.fosdempgday.org/ Prague PostgreSQL Developer Day 2019 (P2D2 2019) is a two-day conference that will be held on February 13-14, 2019 in Prague, Czech Republic. The CfP is open until January 4, 2018 at https://p2d2.cz/callforpapers http://www.p2d2.cz/ PGConf India 2019 will be on February 13-15, 2019 in Bengaluru, Karnataka. http://pgconf.in/ pgDay Paris 2019 will be held in Paris, France on March 12, 2019 at 199bis rue Saint-Martin. http://2019.pgday.paris/ PGConf APAC 2019 will be held in Singapore March 19-21, 2019. http://2019.pgconfapac.org/ PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy. Both the CfP https://2019.pgday.it/en/blog/cfp and the Call for Workshops https://2019.pgday.it/en/blog/cfw are openuntil January 15, 2019. https://2019.pgday.it/en/ PGCon 2019 will take place in Ottawa on May 28-31, 2019. The CfP is open through January 19, 2019 at http://www.pgcon.org/2019/papers.php https://www.pgcon.org/2018/schedule/ Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019. The CfP is open January 17, 2019 through April 18, 2019, and registration will open January 17, 2019. http://www.pgday.ch/2019/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.org. == Applied Patches == Michaël Paquier pushed: - Ensure cleanup of orphan archive status files. When a WAL segment is recycled, its ".ready" and ".done" status files get also automatically removed, however this is not done in a durable manner. Hence, in a subsequent crash, it could be possible that a ".ready" status file is still around with its corresponding segment already gone. If the backend reaches such a state, the archive command would most likely complain about a segment non-existing and would keep retrying, causing WAL segments to bloat pg_wal/, potentially making Postgres crash hard when running out of space. As status files are removed after each individual segment, using durable_unlink() does not completely close the window either, as a crash could happen between the moment the WAL segment is recycled and the moment its status files are removed. This has also some performance impact with the additional fsync() calls needed to make the removal in a durable manner. Doing the cleanup at recovery is not cost-free either as this makes crash recovery potentially take longer than necessary. So, instead, as per an idea of Stephen Frost, make the archiver aware of orphan status files and remove them on-the-fly if the corresponding segment goes missing. Removal failures follow a model close to what happens for WAL segments, where multiple attempts are done before giving up temporarily, and where a successful orphan removal makes the archiver move immediately to the next WAL segment thought as ready to be archived. Author: Michael Paquier Reviewed-by: Nathan Bossart, Andres Freund, Stephen Frost, Kyotaro Horiguchi Discussion: https://postgr.es/m/20180928032827.GF1500@paquier.xyz https://git.postgresql.org/pg/commitdiff/6d8727f95e7043d52ea8f6d62f7bcf81fdeaa658 - Tweak pg_partition_tree for undefined relations and unsupported relkinds. This fixes a crash which happened when calling the function directly with a relation OID referring to a non-existing object, and changes the behavior so as NULL is returned for unsupported relkinds instead of generating an error. This puts the new function in line with many other system functions, and eases actions like full scans of pg_class. Author: Michael Paquier Reviewed-by: Amit Langote, Stephen Frost Discussion: https://postgr.es/m/20181207010406.GO2407@paquier.xyz https://git.postgresql.org/pg/commitdiff/cc53123bcc9d8786acae2885c3a0897b7be34a02 - Introduce new extended routines for FDW and foreign server lookups. The cache lookup routines for foreign-data wrappers and foreign servers are extended with an extra argument to handle a set of flags. The only value which can be used now is to indicate if a missing object should result in an error or not, and are designed to be extensible on need. Those new routines are added into the existing set of user-visible FDW APIs and documented in consequence. They will be used for future patches to improve the SQL interface for object addresses. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8fb569e978af3995f0dd6b0033758ec571aab0c1 Stephen Frost pushed: - Remove dead code in toast_fetch_datum_slice. In toast_fetch_datum_slice(), we Assert() that what is passed in isn't compressed, but we then later had a check to see what the length of if what was passed in is compressed. That later check is rather confusing since toast_fetch_datum_slice() is only ever called with non-compressed datums and the Assert() earlier makes it clear that one shouldn't be passing in compressed datums. Add a comment to make it clear that toast_fetch_datum_slice() is just for non-compressed datums, and remove the dead code. https://git.postgresql.org/pg/commitdiff/96c702c1edbde8a3f5013bd0ac6c25c85710258d - Add additional partition tests to pg_dump. This adds a few tests for non-inherited constraints. Author: Amit Langote Discussion: https://postgr.es/m/20181208001735.GT3415%40tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/2d7eeb1b14925fd4ba6d2d7012636489570eaee8 - Add pg_dump test for empty OP class. This adds a pg_dump test for an empty operator class. Author: Michael Paquier Discussion: https://postgr.es/m/20181208011142.GU3415@tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/eeeb1dfc87fafe1cf4332c09692779662a95511e Tom Lane pushed: - Make TupleDescInitBuiltinEntry throw error for unsupported types. Previously, it would just pass back a partially-uninitialized tupdesc, which doesn't seem like a safe or useful behavior. Backpatch to v10 where this code came in. Discussion: https://postgr.es/m/30830.1544384975@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b7a29695f744c3140350a4f1bb8511e950acc086 - Doc: remove obsolete reference to recursive expression evaluation. John Naylor Discussion: https://postgr.es/m/CAJVSVGUPH-0q5feP4v9b+Y8K3HGTn3bEd5KV7VbyUj-oFdSLzA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e28649a67f56ee1f7c1a55dc3dee4a1e467430a4 - Add stack depth checks to key recursive functions in backend/nodes/*.c. Although copyfuncs.c has a check_stack_depth call in its recursion, equalfuncs.c, outfuncs.c, and readfuncs.c lacked one. This seems unwise. Likewise fix planstate_tree_walker(), in branches where that exists. Discussion: https://postgr.es/m/30253.1544286631@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/001bb9f3ed05e7c370151f7aad3a83447c52c157 - Doc: improve documentation about ALTER LARGE OBJECT requirements. Unlike other ALTER ref pages, this one neglected to mention that ALTER OWNER requires being a member of the new owning role. Per bug #15546 from Stefan Kadow. Discussion: https://postgr.es/m/15546-0558c75fd2025e7c@postgresql.org https://git.postgresql.org/pg/commitdiff/d65ddb2b5674cd6cf444c4825270a12b968055ac - Fix test_rls_hooks to assign expression collations properly. This module overlooked this necessary fixup step on the results of transformWhereClause(). It accidentally worked anyway, because the constructed expression involved type "name" which is not collatable, but it fell over while I was experimenting with changing "name" to be collatable. Back-patch, not because there's any live bug here in back branches, but because somebody might use this code as a model for some real application and then not understand why it doesn't work. https://git.postgresql.org/pg/commitdiff/7a28e9aa0fd966ed374d244896e397148336720a - Repair bogus handling of multi-assignment Params in upper plan levels. Our support for multiple-set-clauses in UPDATE assumes that the Params referencing a MULTIEXPR_SUBLINK SubPlan will appear before that SubPlan in the targetlist of the plan node that calculates the updated row. (Yeah, it's a hack...) In some PG branches it's possible that a Result node gets inserted between the primary calculation of the update tlist and the ModifyTable node. setrefs.c did the wrong thing in this case and left the upper-level Params as Params, causing a crash at runtime. What it should do is replace them with "outer" Vars referencing the child plan node's output. That's a result of careless ordering of operations in fix_upper_expr_mutator, so we can fix it just by reordering the code. Fix fix_join_expr_mutator similarly for consistency, even though join nodes could never appear in such a context. (In general, it seems likely to be a bit cheaper to use Vars than Params in such situations anyway, so this patch might offer a tiny performance improvement.) The hazard extends back to 9.5 where the MULTIEXPR_SUBLINK stuff was introduced, so back-patch that far. However, this may be a live bug only in 9.6.x and 10.x, as the other branches don't seem to want to calculate the final tlist below the Result node. (That plan shape change between branches might be a mini-bug in itself, but I'm not really interested in digging into the reasons for that right now. Still, add a regression test memorializing what we expect there, so we'll notice if it changes again.) Per bug report from Eduards Bezverhijs. Discussion: https://postgr.es/m/b6cd572a-3e44-8785-75e9-c512a5a17a73@tieto.com https://git.postgresql.org/pg/commitdiff/0f7ec8d9c3aeb8964d3539561e5c8d4caef42bf6 - Repair bogus EPQ plans generated for postgres_fdw foreign joins. postgres_fdw's postgresGetForeignPlan() assumes without checking that the outer_plan it's given for a join relation must have a NestLoop, MergeJoin, or HashJoin node at the top. That's been wrong at least since commit 4bbf6edfb (which could cause insertion of a Sort node on top) and it seems like a pretty unsafe thing to Just Assume even without that. Through blind good fortune, this doesn't seem to have any worse consequences today than strange EXPLAIN output, but it's clearly trouble waiting to happen. To fix, test the node type explicitly before touching Join-specific fields, and avoid jamming the new tlist into a node type that can't do projection. Export a new support function from createplan.c to avoid building low-level knowledge about the latter into FDWs. Back-patch to 9.6 where the faulty coding was added. Note that the associated regression test cases don't show any changes before v11, apparently because the tests back-patched with 4bbf6edfb don't actually exercise the problem case before then (there's no top-level Sort in those plans). Discussion: https://postgr.es/m/8946.1544644803@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/77d4d88afbaa37773d15578d89881fa175ec38e8 - Drop no-op CoerceToDomain nodes from expressions at planning time. If a domain has no constraints, then CoerceToDomain doesn't really do anything and can be simplified to a RelabelType. This not only eliminates cycles at execution, but allows the planner to optimize better (for instance, match the coerced expression to an index on the underlying column). However, we do have to support invalidating the plan later if a constraint gets added to the domain. That's comparable to the case of a change to a SQL function that had been inlined into a plan, so all the necessary logic already exists for plans depending on functions. We need only duplicate or share that logic for domains. ALTER DOMAIN ADD/DROP CONSTRAINT need to be taught to send out sinval messages for the domain's pg_type entry, since those operations don't update that row. (ALTER DOMAIN SET/DROP NOT NULL do update that row, so no code change is needed for them.) Testing this revealed what's really a pre-existing bug in plpgsql: it caches the SQL-expression-tree expansion of type coercions and had no provision for invalidating entries in that cache. Up to now that was only a problem if such an expression had inlined a SQL function that got changed, which is unlikely though not impossible. But failing to track changes of domain constraints breaks an existing regression test case and would likely cause practical problems too. We could fix that locally in plpgsql, but what seems like a better idea is to build some generic infrastructure in plancache.c to store standalone expressions and track invalidation events for them. (It's tempting to wonder whether plpgsql's "simple expression" stuff could use this code with lower overhead than its current use of the heavyweight plancache APIs. But I've left that idea for later.) Other stuff fixed in passing: * Allow estimate_expression_value() to drop CoerceToDomain unconditionally, effectively assuming that the coercion will succeed. This will improve planner selectivity estimates for cases involving estimatable expressions that are coerced to domains. We could have done this independently of everything else here, but there wasn't previously any need for eval_const_expressions_mutator to know about CoerceToDomain at all. * Use a dlist for plancache.c's list of cached plans, rather than a manually threaded singly-linked list. That eliminates a potential performance problem in DropCachedPlan. * Fix a couple of inconsistencies in typecmds.c about whether operations on domains drop RowExclusiveLock on pg_type. Our common practice is that DDL operations do drop catalog locks, so standardize on that choice. Discussion: https://postgr.es/m/19958.1544122124@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/04fe805a1734eccd8dcdd34c8cc0ddcb62c7240c - Fix bogus logic for skipping unnecessary partcollation dependencies. The idea here is to not call recordDependencyOn for the default collation, since we know that's pinned. But what the code actually did was to record the partition key's dependency on the opclass twice, instead. Evidently introduced by sloppy coding in commit 2186b608b. Back-patch to v10 where that came in. https://git.postgresql.org/pg/commitdiff/84d514887f9ca673ae688d00f8b544e70f1ab270 - Make pg_statistic and related code account more honestly for collations. When we first put in collations support, we basically punted on teaching pg_statistic, ANALYZE, and the planner selectivity functions about that. They've just used DEFAULT_COLLATION_OID independently of the actual collation of the data. It's time to improve that, so: * Add columns to pg_statistic that record the specific collation associated with each statistics slot. * Teach ANALYZE to use the column's actual collation when comparing values for statistical purposes, and record this in the appropriate slot. (Note that type-specific typanalyze functions are now expected to fill stats->stacoll with the appropriate collation, too.) * Teach assorted selectivity functions to use the actual collation of the stats they are looking at, instead of just assuming it's DEFAULT_COLLATION_OID. This should give noticeably better results in selectivity estimates for columns with nondefault collations, at least for query clauses that use that same collation (which would be the default behavior in most cases). It's still true that comparisons with explicit COLLATE clauses different from the stored data's collation won't be well-estimated, but that's no worse than before. Also, this patch does make the first step towards doing better with that, which is that it's now theoretically possible to collect stats for a collation other than the column's own collation. Patch by me; thanks to Peter Eisentraut for review. Discussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5e09280057a4c3f5db297348ea3e044c9c5f4ef8 - Make error handling in parallel pg_upgrade less bogus. reap_child() basically ignored the possibility of either an error in waitpid() itself or a child process failure on signal. We don't really need to do more than report and crash hard, but proceeding as though nothing is wrong is definitely Not Acceptable. The error report for nonzero child exit status was pretty off-point, as well. Noted while fooling around with child-process failure detection logic elsewhere. It's been like this a long time, so back-patch to all supported branches. https://git.postgresql.org/pg/commitdiff/16fda4b853cd5bc07c450303a465ed9d451c7b47 - Improve detection of child-process SIGPIPE failures. Commit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child process, but it only worked correctly if the SIGPIPE occurred in the immediate child process. Depending on the shell in use and the complexity of the shell command string, we might instead get back an exit code of 128 + SIGPIPE, representing a shell error exit reporting SIGPIPE in the child process. We could just hack up ClosePipeToProgram() to add the extra case, but it seems like this is a fairly general issue deserving a more general and better-documented solution. I chose to add a couple of functions in src/common/wait_error.c, which is a natural place to know about wait-result encodings, that will test for either a specific child-process signal type or any child-process signal failure. Then, adjust other places that were doing ad-hoc tests of this type to use the common functions. In RestoreArchivedFile, this fixes a race condition affecting whether the process will report an error or just silently proc_exit(1): before, that depended on whether the intermediate shell got SIGTERM'd itself or reported a child process failing on SIGTERM. Like the previous patch, back-patch to v10; we could go further but there seems no real need to. Per report from Erik Rijkers. Discussion: https://postgr.es/m/f3683f87ab1701bea5d86a7742b22432@xs4all.nl https://git.postgresql.org/pg/commitdiff/ade2d61ed09c11a3d374a98c66c8a05cb82a0069 Noah Misch pushed: - Raise some timeouts to 180s, in test code. Slow runs of buildfarm members chipmunk, hornet and mandrill saw the shorter timeouts expire. The 180s timeout in poll_query_until has been trouble-free since 2a0f89cd717ce6d49cdc47850577823682167e87 introduced it two years ago, so use 180s more widely. Back-patch to 9.6, where the first of these timeouts was introduced. Reviewed by Michael Paquier. Discussion: https://postgr.es/m/20181209001601.GC2973271@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/1db439ad49255d8fb0371cc7166cdc33f6b3fdf3 Alexander Korotkov pushed: - Fix deadlock in GIN vacuum introduced by 218f51584d5. Before 218f51584d5 if posting tree page is about to be deleted, then the whole posting tree is locked by LockBufferForCleanup() on root preventing all the concurrent inserts. 218f51584d5 reduced locking to the subtree containing page to be deleted. However, due to concurrent parent split, inserter doesn't always holds pins on all the pages constituting path from root to the target leaf page. That could cause a deadlock between GIN vacuum process and GIN inserter. And we didn't find non-invasive way to fix this. This commit reverts VACUUM behavior to lock the whole posting tree before delete any page. However, we keep another useful change by 218f51584d5: the tree is locked only if there are pages to be deleted. Reported-by: Chen Huajun Diagnosed-by: Chen Huajun, Andrey Borodin, Peter Geoghegan Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Alexander Korotkov, based on ideas from Andrey Borodin and Peter Geoghegan Reviewed-by: Andrey Borodin Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/fd83c83d0943a6717dbe521efa10da9dce94e4cd - Prevent deadlock in ginRedoDeletePage(). On standby ginRedoDeletePage() can work concurrently with read-only queries. Those queries can traverse posting tree in two ways. 1) Using rightlinks by ginStepRight(), which locks the next page before unlocking its left sibling. 2) Using downlinks by ginFindLeafPage(), which locks at most one page at time. Original lock order was: page, parent, left sibling. That lock order can deadlock with ginStepRight(). In order to prevent deadlock this commit changes lock order to: left sibling, page, parent. Note, that position of parent in locking order seems insignificant, because we only lock one page at time while traversing downlinks. Reported-by: Chen Huajun Diagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Alexander Korotkov Backpatch-through: 9.4 https://git.postgresql.org/pg/commitdiff/c6ade7a8cd3135af0c5d29abf39a6a83b9f6a66a - Prevent GIN deleted pages from being reclaimed too early. When GIN vacuum deletes a posting tree page, it assumes that no concurrent searchers can access it, thanks to ginStepRight() locking two pages at once. However, since 9.4 searches can skip parts of posting trees descending from the root. That leads to the risk that page is deleted and reclaimed before concurrent search can access it. This commit prevents the risk of above by waiting for every transaction, which might wait to reference this page, to finish. Due to binary compatibility we can't change GinPageOpaqueData to store corresponding transaction id. Instead we reuse page header pd_prune_xid field, which is unused in index pages. Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Andrey Borodin, Alexander Korotkov Reviewed-by: Alexander Korotkov Backpatch-through: 9.4 https://git.postgresql.org/pg/commitdiff/52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478 Andres Freund pushed: - Create a separate oid range for oids assigned by genbki.pl. The changes I made in 578b229718e assigned oids below FirstBootstrapObjectId to objects in include/catalog/*.dat files that did not have an oid assigned, starting at the max oid explicitly assigned. Tom criticized that for mainly two reasons: 1) It's not clear which values are manually and which explicitly assigned. 2) The space below FirstBootstrapObjectId gets pretty crowded, and some PostgreSQL forks have used oids >= 9000 for their own objects, to avoid conflicting. Thus create a new range for objects not assigned explicit oids, but assigned by genbki.pl. For now 1-9999 is for explicitly assigned oids, FirstGenbkiObjectId (10000) to FirstBootstrapObjectId (1200) -1 is for genbki.pl assigned oids, and < FirstNormalObjectId (16384) is for oids assigned during bootstrap. It's possible that we'll have to adjust these boundaries, but there's some headroom for now. Add a note suggesting that oids in forks should be assigned in the 9000-9999 range. Catversion bump for obvious reasons. Per complaint from Tom Lane. Author: Andres Freund Discussion: https://postgr.es/m/16845.1544393682@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/09568ec3d31bbd4854b857e8d23c197ad5b25c77 == Pending Patches == Sergey Cherkashin sent in another revision of a patch to add \dA for access methods and more \di for indexes related to same to psql. Dmitry Dolgov sent in another revision of a patch to add PMDK support. David Rowley sent in two more revisions of a patch to allow newly created partitions to inherit their parent's tablespace. Peter Eisentraut sent in two revisions of a patch to reorganize collation lookup time and place. David Steele sent in two revisions of a patch to add timeline to partial WAL segments. Sergei Kornilov sent in another revision of a patch to allow changing primary_conninfo for walreceiver without a server restart. David Steele sent in another revision of a patch to remove the deprecated exclusive backup mode. Richard Guo sent in a patch to add a fast path for empty relids in check_outerjoin_delay(). Dilip Kumar sent in another revision of a patch to provide an interface for prepare, insert, or fetch the undo records. Adrien Nayrat sent in a patch to add a log_transaction_sample_rate GUC. Surafel Temesgen sent in another revision of a patch to add a WHERE clause to COPY ... FROM. Andres Freund sent in two revisions of a patch to implement minimal logical decoding on standbys. Michaël Paquier sent in two revisions of a patch to make WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name. Michaël Paquier sent in two more revisions of a patch to add a pg_partition_root() function. Andres Freund sent in another revision of a patch to partition the OID namespace more precisely. John Naylor sent in a patch to remove a special case from src/backend/storage/smgr/md.c which was interfering with the above partitioning. Haribabu Kommi sent in another revision of a patch to extend pg_stat_statements_reset to reset statistics specific to a particular user/db/query. Alexander Korotkov sent in another revision of a patch to make LWLocks more fair. Andreas Karlsson and Chapman Flack traded patches to add SNI in TLS handshake for SSL connections. Kyotaro HORIGUCHI sent in another revision of a patch to make psql built with the TABCOMPLETION_DEBUG defined emit a tab-completion debug log into the file specified with the -L option, and a similar one with -g meaning "Log all debugging options." Peter Eisentraut sent in a patch to add a PG_FINALLY. David Steele sent in a patch to add a FINALLY, where at least one of CATCH and FINALLY must be specified. Andrew Gierth sent in four more revisions of a patch to implement the Ryu output optimization for floating point numbers. David Steele sent in two revisions of a patch to change pgarch_readyXlog() to return .history files first. Amit Langote sent in a patch to clarify the documentation about runtime partition pruning. Amit Langote sent in a patch to disallow creating partitions with mismatching collations for columns. Rushabh Lathia sent in another revision of a patch to fix index locking for deletes. John Naylor sent in another revision of a patch to add pg_language lookup and replace the /ad hoc/ format for conversion functions in BKI. John Naylor sent in another revision of a patch to use single-byte Boyer-Moore-Horspool search even with multibyte encodings. Suraj Kharage sent in a patch to ensure that pg_indexes includes indexes on partitions. Tomáš Vondra sent in a patch to add a option to show pertinent modified GUCs in EXPLAIN. Andres Freund sent in a patch to compute the conflict xid for index page-level-vacuum on primary. Álvaro Herrera sent in another revision of a patch to remove dangling temp tables. Alexey Bashtanov sent in a patch to log bind parameter values on error. Tom Lane sent in a patch to fix an infelicity between ExecBuildGroupingEqual and collations. Dmitry Dolgov sent in a patch to add access methods to psql's describe displays. Tom Lane sent in a patch to use the C collation in catalogs. Tom Lane sent in a patch to fix a mergejoin cost estimate thinko. Pavel Stěhule sent in another revision of a patch to add a block-level PRAGMA to PL/pgsql. Pavel Stěhule sent in a patch to fix an issue in plpgsql plugins where stmt_beg/end was not called for the top-level block of statements. Lætitia Avrot sent in a patch to clarify the fact that GRANT ... ON ALL TABLES includes a grant in materialized views. Daniel Vérité sent in a patch to add a \copyout statement terminator to psql in the spirit of \g. Tomáš Vondra sent in another revision of a patch to add logical_work_mem. David Rowley sent in a patch to remove double trailing semicolons. Álvaro Herrera sent in a patch to fix an issue where reorderbuffer would consume too much memory with medium-size subxacts. Álvaro Herrera sent in a patch to remove the create_storage parameter. Tom Lane sent in a patch to plaster COLLATE "C" on each textual table column in the information_schema, and another to attach COLLATE "C" to each of the domain types that information_schema defines, both in pursuit of better performance in queries on the information schema. == Applied Patches == Michaël Paquier pushed: - Ensure cleanup of orphan archive status files. When a WAL segment is recycled, its ".ready" and ".done" status files get also automatically removed, however this is not done in a durable manner. Hence, in a subsequent crash, it could be possible that a ".ready" status file is still around with its corresponding segment already gone. If the backend reaches such a state, the archive command would most likely complain about a segment non-existing and would keep retrying, causing WAL segments to bloat pg_wal/, potentially making Postgres crash hard when running out of space. As status files are removed after each individual segment, using durable_unlink() does not completely close the window either, as a crash could happen between the moment the WAL segment is recycled and the moment its status files are removed. This has also some performance impact with the additional fsync() calls needed to make the removal in a durable manner. Doing the cleanup at recovery is not cost-free either as this makes crash recovery potentially take longer than necessary. So, instead, as per an idea of Stephen Frost, make the archiver aware of orphan status files and remove them on-the-fly if the corresponding segment goes missing. Removal failures follow a model close to what happens for WAL segments, where multiple attempts are done before giving up temporarily, and where a successful orphan removal makes the archiver move immediately to the next WAL segment thought as ready to be archived. Author: Michael Paquier Reviewed-by: Nathan Bossart, Andres Freund, Stephen Frost, Kyotaro Horiguchi Discussion: https://postgr.es/m/20180928032827.GF1500@paquier.xyz https://git.postgresql.org/pg/commitdiff/6d8727f95e7043d52ea8f6d62f7bcf81fdeaa658 - Tweak pg_partition_tree for undefined relations and unsupported relkinds. This fixes a crash which happened when calling the function directly with a relation OID referring to a non-existing object, and changes the behavior so as NULL is returned for unsupported relkinds instead of generating an error. This puts the new function in line with many other system functions, and eases actions like full scans of pg_class. Author: Michael Paquier Reviewed-by: Amit Langote, Stephen Frost Discussion: https://postgr.es/m/20181207010406.GO2407@paquier.xyz https://git.postgresql.org/pg/commitdiff/cc53123bcc9d8786acae2885c3a0897b7be34a02 - Introduce new extended routines for FDW and foreign server lookups. The cache lookup routines for foreign-data wrappers and foreign servers are extended with an extra argument to handle a set of flags. The only value which can be used now is to indicate if a missing object should result in an error or not, and are designed to be extensible on need. Those new routines are added into the existing set of user-visible FDW APIs and documented in consequence. They will be used for future patches to improve the SQL interface for object addresses. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8fb569e978af3995f0dd6b0033758ec571aab0c1 Stephen Frost pushed: - Remove dead code in toast_fetch_datum_slice. In toast_fetch_datum_slice(), we Assert() that what is passed in isn't compressed, but we then later had a check to see what the length of if what was passed in is compressed. That later check is rather confusing since toast_fetch_datum_slice() is only ever called with non-compressed datums and the Assert() earlier makes it clear that one shouldn't be passing in compressed datums. Add a comment to make it clear that toast_fetch_datum_slice() is just for non-compressed datums, and remove the dead code. https://git.postgresql.org/pg/commitdiff/96c702c1edbde8a3f5013bd0ac6c25c85710258d - Add additional partition tests to pg_dump. This adds a few tests for non-inherited constraints. Author: Amit Langote Discussion: https://postgr.es/m/20181208001735.GT3415%40tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/2d7eeb1b14925fd4ba6d2d7012636489570eaee8 - Add pg_dump test for empty OP class. This adds a pg_dump test for an empty operator class. Author: Michael Paquier Discussion: https://postgr.es/m/20181208011142.GU3415@tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/eeeb1dfc87fafe1cf4332c09692779662a95511e Tom Lane pushed: - Make TupleDescInitBuiltinEntry throw error for unsupported types. Previously, it would just pass back a partially-uninitialized tupdesc, which doesn't seem like a safe or useful behavior. Backpatch to v10 where this code came in. Discussion: https://postgr.es/m/30830.1544384975@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b7a29695f744c3140350a4f1bb8511e950acc086 - Doc: remove obsolete reference to recursive expression evaluation. John Naylor Discussion: https://postgr.es/m/CAJVSVGUPH-0q5feP4v9b+Y8K3HGTn3bEd5KV7VbyUj-oFdSLzA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e28649a67f56ee1f7c1a55dc3dee4a1e467430a4 - Add stack depth checks to key recursive functions in backend/nodes/*.c. Although copyfuncs.c has a check_stack_depth call in its recursion, equalfuncs.c, outfuncs.c, and readfuncs.c lacked one. This seems unwise. Likewise fix planstate_tree_walker(), in branches where that exists. Discussion: https://postgr.es/m/30253.1544286631@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/001bb9f3ed05e7c370151f7aad3a83447c52c157 - Doc: improve documentation about ALTER LARGE OBJECT requirements. Unlike other ALTER ref pages, this one neglected to mention that ALTER OWNER requires being a member of the new owning role. Per bug #15546 from Stefan Kadow. Discussion: https://postgr.es/m/15546-0558c75fd2025e7c@postgresql.org https://git.postgresql.org/pg/commitdiff/d65ddb2b5674cd6cf444c4825270a12b968055ac - Fix test_rls_hooks to assign expression collations properly. This module overlooked this necessary fixup step on the results of transformWhereClause(). It accidentally worked anyway, because the constructed expression involved type "name" which is not collatable, but it fell over while I was experimenting with changing "name" to be collatable. Back-patch, not because there's any live bug here in back branches, but because somebody might use this code as a model for some real application and then not understand why it doesn't work. https://git.postgresql.org/pg/commitdiff/7a28e9aa0fd966ed374d244896e397148336720a - Repair bogus handling of multi-assignment Params in upper plan levels. Our support for multiple-set-clauses in UPDATE assumes that the Params referencing a MULTIEXPR_SUBLINK SubPlan will appear before that SubPlan in the targetlist of the plan node that calculates the updated row. (Yeah, it's a hack...) In some PG branches it's possible that a Result node gets inserted between the primary calculation of the update tlist and the ModifyTable node. setrefs.c did the wrong thing in this case and left the upper-level Params as Params, causing a crash at runtime. What it should do is replace them with "outer" Vars referencing the child plan node's output. That's a result of careless ordering of operations in fix_upper_expr_mutator, so we can fix it just by reordering the code. Fix fix_join_expr_mutator similarly for consistency, even though join nodes could never appear in such a context. (In general, it seems likely to be a bit cheaper to use Vars than Params in such situations anyway, so this patch might offer a tiny performance improvement.) The hazard extends back to 9.5 where the MULTIEXPR_SUBLINK stuff was introduced, so back-patch that far. However, this may be a live bug only in 9.6.x and 10.x, as the other branches don't seem to want to calculate the final tlist below the Result node. (That plan shape change between branches might be a mini-bug in itself, but I'm not really interested in digging into the reasons for that right now. Still, add a regression test memorializing what we expect there, so we'll notice if it changes again.) Per bug report from Eduards Bezverhijs. Discussion: https://postgr.es/m/b6cd572a-3e44-8785-75e9-c512a5a17a73@tieto.com https://git.postgresql.org/pg/commitdiff/0f7ec8d9c3aeb8964d3539561e5c8d4caef42bf6 - Repair bogus EPQ plans generated for postgres_fdw foreign joins. postgres_fdw's postgresGetForeignPlan() assumes without checking that the outer_plan it's given for a join relation must have a NestLoop, MergeJoin, or HashJoin node at the top. That's been wrong at least since commit 4bbf6edfb (which could cause insertion of a Sort node on top) and it seems like a pretty unsafe thing to Just Assume even without that. Through blind good fortune, this doesn't seem to have any worse consequences today than strange EXPLAIN output, but it's clearly trouble waiting to happen. To fix, test the node type explicitly before touching Join-specific fields, and avoid jamming the new tlist into a node type that can't do projection. Export a new support function from createplan.c to avoid building low-level knowledge about the latter into FDWs. Back-patch to 9.6 where the faulty coding was added. Note that the associated regression test cases don't show any changes before v11, apparently because the tests back-patched with 4bbf6edfb don't actually exercise the problem case before then (there's no top-level Sort in those plans). Discussion: https://postgr.es/m/8946.1544644803@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/77d4d88afbaa37773d15578d89881fa175ec38e8 - Drop no-op CoerceToDomain nodes from expressions at planning time. If a domain has no constraints, then CoerceToDomain doesn't really do anything and can be simplified to a RelabelType. This not only eliminates cycles at execution, but allows the planner to optimize better (for instance, match the coerced expression to an index on the underlying column). However, we do have to support invalidating the plan later if a constraint gets added to the domain. That's comparable to the case of a change to a SQL function that had been inlined into a plan, so all the necessary logic already exists for plans depending on functions. We need only duplicate or share that logic for domains. ALTER DOMAIN ADD/DROP CONSTRAINT need to be taught to send out sinval messages for the domain's pg_type entry, since those operations don't update that row. (ALTER DOMAIN SET/DROP NOT NULL do update that row, so no code change is needed for them.) Testing this revealed what's really a pre-existing bug in plpgsql: it caches the SQL-expression-tree expansion of type coercions and had no provision for invalidating entries in that cache. Up to now that was only a problem if such an expression had inlined a SQL function that got changed, which is unlikely though not impossible. But failing to track changes of domain constraints breaks an existing regression test case and would likely cause practical problems too. We could fix that locally in plpgsql, but what seems like a better idea is to build some generic infrastructure in plancache.c to store standalone expressions and track invalidation events for them. (It's tempting to wonder whether plpgsql's "simple expression" stuff could use this code with lower overhead than its current use of the heavyweight plancache APIs. But I've left that idea for later.) Other stuff fixed in passing: * Allow estimate_expression_value() to drop CoerceToDomain unconditionally, effectively assuming that the coercion will succeed. This will improve planner selectivity estimates for cases involving estimatable expressions that are coerced to domains. We could have done this independently of everything else here, but there wasn't previously any need for eval_const_expressions_mutator to know about CoerceToDomain at all. * Use a dlist for plancache.c's list of cached plans, rather than a manually threaded singly-linked list. That eliminates a potential performance problem in DropCachedPlan. * Fix a couple of inconsistencies in typecmds.c about whether operations on domains drop RowExclusiveLock on pg_type. Our common practice is that DDL operations do drop catalog locks, so standardize on that choice. Discussion: https://postgr.es/m/19958.1544122124@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/04fe805a1734eccd8dcdd34c8cc0ddcb62c7240c - Fix bogus logic for skipping unnecessary partcollation dependencies. The idea here is to not call recordDependencyOn for the default collation, since we know that's pinned. But what the code actually did was to record the partition key's dependency on the opclass twice, instead. Evidently introduced by sloppy coding in commit 2186b608b. Back-patch to v10 where that came in. https://git.postgresql.org/pg/commitdiff/84d514887f9ca673ae688d00f8b544e70f1ab270 - Make pg_statistic and related code account more honestly for collations. When we first put in collations support, we basically punted on teaching pg_statistic, ANALYZE, and the planner selectivity functions about that. They've just used DEFAULT_COLLATION_OID independently of the actual collation of the data. It's time to improve that, so: * Add columns to pg_statistic that record the specific collation associated with each statistics slot. * Teach ANALYZE to use the column's actual collation when comparing values for statistical purposes, and record this in the appropriate slot. (Note that type-specific typanalyze functions are now expected to fill stats->stacoll with the appropriate collation, too.) * Teach assorted selectivity functions to use the actual collation of the stats they are looking at, instead of just assuming it's DEFAULT_COLLATION_OID. This should give noticeably better results in selectivity estimates for columns with nondefault collations, at least for query clauses that use that same collation (which would be the default behavior in most cases). It's still true that comparisons with explicit COLLATE clauses different from the stored data's collation won't be well-estimated, but that's no worse than before. Also, this patch does make the first step towards doing better with that, which is that it's now theoretically possible to collect stats for a collation other than the column's own collation. Patch by me; thanks to Peter Eisentraut for review. Discussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5e09280057a4c3f5db297348ea3e044c9c5f4ef8 - Make error handling in parallel pg_upgrade less bogus. reap_child() basically ignored the possibility of either an error in waitpid() itself or a child process failure on signal. We don't really need to do more than report and crash hard, but proceeding as though nothing is wrong is definitely Not Acceptable. The error report for nonzero child exit status was pretty off-point, as well. Noted while fooling around with child-process failure detection logic elsewhere. It's been like this a long time, so back-patch to all supported branches. https://git.postgresql.org/pg/commitdiff/16fda4b853cd5bc07c450303a465ed9d451c7b47 - Improve detection of child-process SIGPIPE failures. Commit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child process, but it only worked correctly if the SIGPIPE occurred in the immediate child process. Depending on the shell in use and the complexity of the shell command string, we might instead get back an exit code of 128 + SIGPIPE, representing a shell error exit reporting SIGPIPE in the child process. We could just hack up ClosePipeToProgram() to add the extra case, but it seems like this is a fairly general issue deserving a more general and better-documented solution. I chose to add a couple of functions in src/common/wait_error.c, which is a natural place to know about wait-result encodings, that will test for either a specific child-process signal type or any child-process signal failure. Then, adjust other places that were doing ad-hoc tests of this type to use the common functions. In RestoreArchivedFile, this fixes a race condition affecting whether the process will report an error or just silently proc_exit(1): before, that depended on whether the intermediate shell got SIGTERM'd itself or reported a child process failing on SIGTERM. Like the previous patch, back-patch to v10; we could go further but there seems no real need to. Per report from Erik Rijkers. Discussion: https://postgr.es/m/f3683f87ab1701bea5d86a7742b22432@xs4all.nl https://git.postgresql.org/pg/commitdiff/ade2d61ed09c11a3d374a98c66c8a05cb82a0069 Noah Misch pushed: - Raise some timeouts to 180s, in test code. Slow runs of buildfarm members chipmunk, hornet and mandrill saw the shorter timeouts expire. The 180s timeout in poll_query_until has been trouble-free since 2a0f89cd717ce6d49cdc47850577823682167e87 introduced it two years ago, so use 180s more widely. Back-patch to 9.6, where the first of these timeouts was introduced. Reviewed by Michael Paquier. Discussion: https://postgr.es/m/20181209001601.GC2973271@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/1db439ad49255d8fb0371cc7166cdc33f6b3fdf3 Alexander Korotkov pushed: - Fix deadlock in GIN vacuum introduced by 218f51584d5. Before 218f51584d5 if posting tree page is about to be deleted, then the whole posting tree is locked by LockBufferForCleanup() on root preventing all the concurrent inserts. 218f51584d5 reduced locking to the subtree containing page to be deleted. However, due to concurrent parent split, inserter doesn't always holds pins on all the pages constituting path from root to the target leaf page. That could cause a deadlock between GIN vacuum process and GIN inserter. And we didn't find non-invasive way to fix this. This commit reverts VACUUM behavior to lock the whole posting tree before delete any page. However, we keep another useful change by 218f51584d5: the tree is locked only if there are pages to be deleted. Reported-by: Chen Huajun Diagnosed-by: Chen Huajun, Andrey Borodin, Peter Geoghegan Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Alexander Korotkov, based on ideas from Andrey Borodin and Peter Geoghegan Reviewed-by: Andrey Borodin Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/fd83c83d0943a6717dbe521efa10da9dce94e4cd - Prevent deadlock in ginRedoDeletePage(). On standby ginRedoDeletePage() can work concurrently with read-only queries. Those queries can traverse posting tree in two ways. 1) Using rightlinks by ginStepRight(), which locks the next page before unlocking its left sibling. 2) Using downlinks by ginFindLeafPage(), which locks at most one page at time. Original lock order was: page, parent, left sibling. That lock order can deadlock with ginStepRight(). In order to prevent deadlock this commit changes lock order to: left sibling, page, parent. Note, that position of parent in locking order seems insignificant, because we only lock one page at time while traversing downlinks. Reported-by: Chen Huajun Diagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Alexander Korotkov Backpatch-through: 9.4 https://git.postgresql.org/pg/commitdiff/c6ade7a8cd3135af0c5d29abf39a6a83b9f6a66a - Prevent GIN deleted pages from being reclaimed too early. When GIN vacuum deletes a posting tree page, it assumes that no concurrent searchers can access it, thanks to ginStepRight() locking two pages at once. However, since 9.4 searches can skip parts of posting trees descending from the root. That leads to the risk that page is deleted and reclaimed before concurrent search can access it. This commit prevents the risk of above by waiting for every transaction, which might wait to reference this page, to finish. Due to binary compatibility we can't change GinPageOpaqueData to store corresponding transaction id. Instead we reuse page header pd_prune_xid field, which is unused in index pages. Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com Author: Andrey Borodin, Alexander Korotkov Reviewed-by: Alexander Korotkov Backpatch-through: 9.4 https://git.postgresql.org/pg/commitdiff/52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478 Andres Freund pushed: - Create a separate oid range for oids assigned by genbki.pl. The changes I made in 578b229718e assigned oids below FirstBootstrapObjectId to objects in include/catalog/*.dat files that did not have an oid assigned, starting at the max oid explicitly assigned. Tom criticized that for mainly two reasons: 1) It's not clear which values are manually and which explicitly assigned. 2) The space below FirstBootstrapObjectId gets pretty crowded, and some PostgreSQL forks have used oids >= 9000 for their own objects, to avoid conflicting. Thus create a new range for objects not assigned explicit oids, but assigned by genbki.pl. For now 1-9999 is for explicitly assigned oids, FirstGenbkiObjectId (10000) to FirstBootstrapObjectId (1200) -1 is for genbki.pl assigned oids, and < FirstNormalObjectId (16384) is for oids assigned during bootstrap. It's possible that we'll have to adjust these boundaries, but there's some headroom for now. Add a note suggesting that oids in forks should be assigned in the 9000-9999 range. Catversion bump for obvious reasons. Per complaint from Tom Lane. Author: Andres Freund Discussion: https://postgr.es/m/16845.1544393682@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/09568ec3d31bbd4854b857e8d23c197ad5b25c77 == Pending Patches == Sergey Cherkashin sent in another revision of a patch to add \dA for access methods and more \di for indexes related to same to psql. Dmitry Dolgov sent in another revision of a patch to add PMDK support. David Rowley sent in two more revisions of a patch to allow newly created partitions to inherit their parent's tablespace. Peter Eisentraut sent in two revisions of a patch to reorganize collation lookup time and place. David Steele sent in two revisions of a patch to add timeline to partial WAL segments. Sergei Kornilov sent in another revision of a patch to allow changing primary_conninfo for walreceiver without a server restart. David Steele sent in another revision of a patch to remove the deprecated exclusive backup mode. Richard Guo sent in a patch to add a fast path for empty relids in check_outerjoin_delay(). Dilip Kumar sent in another revision of a patch to provide an interface for prepare, insert, or fetch the undo records. Adrien Nayrat sent in a patch to add a log_transaction_sample_rate GUC. Surafel Temesgen sent in another revision of a patch to add a WHERE clause to COPY ... FROM. Andres Freund sent in two revisions of a patch to implement minimal logical decoding on standbys. Michaël Paquier sent in two revisions of a patch to make WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name. Michaël Paquier sent in two more revisions of a patch to add a pg_partition_root() function. Andres Freund sent in another revision of a patch to partition the OID namespace more precisely. John Naylor sent in a patch to remove a special case from src/backend/storage/smgr/md.c which was interfering with the above partitioning. Haribabu Kommi sent in another revision of a patch to extend pg_stat_statements_reset to reset statistics specific to a particular user/db/query. Alexander Korotkov sent in another revision of a patch to make LWLocks more fair. Andreas Karlsson and Chapman Flack traded patches to add SNI in TLS handshake for SSL connections. Kyotaro HORIGUCHI sent in another revision of a patch to make psql built with the TABCOMPLETION_DEBUG defined emit a tab-completion debug log into the file specified with the -L option, and a similar one with -g meaning "Log all debugging options." Peter Eisentraut sent in a patch to add a PG_FINALLY. David Steele sent in a patch to add a FINALLY, where at least one of CATCH and FINALLY must be specified. Andrew Gierth sent in four more revisions of a patch to implement the Ryu output optimization for floating point numbers. David Steele sent in two revisions of a patch to change pgarch_readyXlog() to return .history files first. Amit Langote sent in a patch to clarify the documentation about runtime partition pruning. Amit Langote sent in a patch to disallow creating partitions with mismatching collations for columns. Rushabh Lathia sent in another revision of a patch to fix index locking for deletes. John Naylor sent in another revision of a patch to add pg_language lookup and replace the /ad hoc/ format for conversion functions in BKI. John Naylor sent in another revision of a patch to use single-byte Boyer-Moore-Horspool search even with multibyte encodings. Suraj Kharage sent in a patch to ensure that pg_indexes includes indexes on partitions. Tomáš Vondra sent in a patch to add a option to show pertinent modified GUCs in EXPLAIN. Andres Freund sent in a patch to compute the conflict xid for index page-level-vacuum on primary. Álvaro Herrera sent in another revision of a patch to remove dangling temp tables. Alexey Bashtanov sent in a patch to log bind parameter values on error. Tom Lane sent in a patch to fix an infelicity between ExecBuildGroupingEqual and collations. Dmitry Dolgov sent in a patch to add access methods to psql's describe displays. Tom Lane sent in a patch to use the C collation in catalogs. Tom Lane sent in a patch to fix a mergejoin cost estimate thinko. Pavel Stěhule sent in another revision of a patch to add a block-level PRAGMA to PL/pgsql. Pavel Stěhule sent in a patch to fix an issue in plpgsql plugins where stmt_beg/end was not called for the top-level block of statements. Lætitia Avrot sent in a patch to clarify the fact that GRANT ... ON ALL TABLES includes a grant in materialized views. Daniel Vérité sent in a patch to add a \copyout statement terminator to psql in the spirit of \g. Tomáš Vondra sent in another revision of a patch to add logical_work_mem. David Rowley sent in a patch to remove double trailing semicolons. Álvaro Herrera sent in a patch to fix an issue where reorderbuffer would consume too much memory with medium-size subxacts. Álvaro Herrera sent in a patch to remove the create_storage parameter. Tom Lane sent in a patch to plaster COLLATE "C" on each textual table column in the information_schema, and another to attach COLLATE "C" to each of the domain types that information_schema defines, both in pursuit of better performance in queries on the information schema.
В списке pgsql-announce по дате отправления: