== PostgreSQL Weekly News - May 5, 2019 == - Mailing list pgsql-announce
| From | David Fetter |
|---|---|
| Subject | == PostgreSQL Weekly News - May 5, 2019 == |
| Date | |
| Msg-id | 20190505174437.GA28847@fetter.org Whole thread Raw |
| List | pgsql-announce |
== PostgreSQL Weekly News - May 5, 2019 == == PostgreSQL Product News == pgAdmin4 4.6, a web- and native GUI control center for PostgreSQL, released. https://www.pgadmin.org/docs/pgadmin4/dev/release_notes_4_6.html == PostgreSQL Jobs for May == http://archives.postgresql.org/pgsql-jobs/2019-05/ == PostgreSQL Local == The German-speaking PostgreSQL Conference 2019 will take place on May 10, 2019 in Leipzig. http://2019.pgconf.de/ PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy. https://2019.pgday.it/en/ PgConf Belgium will take place on May 17, 2019 at the UCLL Campus in Haasrode (near Leuven). Registration is open. http://pgconf.be PGCon 2019 will take place in Ottawa on May 28-31, 2019. Registration is open. https://www.pgcon.org/2019 Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019. Registration is open. http://www.pgday.ch/2019/ PostgresLondon 2019 will be July 2-3, 2019 with an optional training day on July 1. http://postgreslondon.org PGConf.Brazil 2019 will take place August 1-3, 2019 in São Paulo. http://pgconf.com.br The first Austrian pgDay, will take place September 6, 2019 at the Hilton Garden Inn in Wiener Neustadt. https://pgday.at/en/ PostgresConf South Africa 2019 will take place in Johannesburg on October 8-9, 2019 The Call for Papers is open through June 30, 2019. https://postgresconf.org/conferences/SouthAfrica2019 == 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 == Tom Lane pushed: - Clean up minor warnings from buildfarm. Be more consistent about use of XXXGetDatum macros in new jsonpath code. This is mostly to avoid having code that looks randomly different from everyplace else that's doing the exact same thing. In pg_regress.c, avoid an unreferenced-function warning from compilers that don't understand pg_attribute_unused(). Putting the function inside the same #ifdef as its only caller is more straightforward coding anyway. In be-secure-openssl.c, avoid use of pg_attribute_unused() on a label. That's pretty creative, but there's no good reason to suppose that it's portable, and there's absolutely no need to use goto's here in the first place. (This wasn't actually causing any buildfarm complaints, but it's new code in v12 so it has no portability track record.) https://git.postgresql.org/pg/commitdiff/e481d26285b160058b093588e062cf3071fea192 - Do pre-release housekeeping on catalog data, and fix jsonpath send/recv. Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks specified by RELEASE_CHANGES. (The only change is 8394 -> 3428.) Also run reformat_dat_file.pl while I'm here. While looking at the reformat diffs, I chanced to notice that type jsonpath had typsend and typreceive = '-', which surely is not the intention given that jsonpath_send and jsonpath_recv exist. Fix that. It's safe to assume that these functions have never been tested :-(. I didn't try, but somebody should. https://git.postgresql.org/pg/commitdiff/c3f67ed6e434333e1bc011afc94c25d9959a86bd - In walreceiver, don't try to do ereport() in a signal handler. This is quite unsafe, even for the case of ereport(FATAL) where we won't return control to the interrupted code, and despite this code's use of a flag to restrict the areas where we'd try to do it. It's possible for example that we interrupt malloc or free while that's holding a lock that's meant to protect against cross-thread interference. Then, any attempt to do malloc or free within ereport() will result in a deadlock, preventing the walreceiver process from exiting in response to SIGTERM. We hypothesize that this explains some hard-to-reproduce failures seen in the buildfarm. Hence, get rid of the immediate-exit code in WalRcvShutdownHandler, as well as the logic associated with WalRcvImmediateInterruptOK. Instead, we need to take care that potentially-blocking operations in the walreceiver's data transmission logic (libpqwalreceiver.c) will respond reasonably promptly to the process's latch becoming set and then call ProcessWalRcvInterrupts. Much of the needed code for that was already present in libpqwalreceiver.c. I refactored things a bit so that all the uses of PQgetResult use latch-aware waiting, but didn't need to do much more. These changes should be enough to ensure that libpqwalreceiver.c will respond promptly to SIGTERM whenever it's waiting to receive data. In principle, it could block for a long time while waiting to send data too, and this patch does nothing to guard against that. I think that that hazard is mostly theoretical though: such blocking should occur only if we fill the kernel's data transmission buffers, and we don't generally send enough data to make that happen without waiting for input. If we find out that the hazard isn't just theoretical, we could fix it by using PQsetnonblocking, but that would require more ticklish changes than I care to make now. This is a bug fix, but it seems like too big a change to push into the back branches without much more testing than there's time for right now. Perhaps we'll back-patch once we have more confidence in the change. Patch by me; thanks to Thomas Munro for review. Discussion: https://postgr.es/m/20190416070119.GK2673@paquier.xyz https://git.postgresql.org/pg/commitdiff/a1a789eb5ac894b4ca4b7742f2dc2d9602116e46 - Clean up handling of constraint_exclusion and enable_partition_pruning. The interaction of these parameters was a bit confused/confusing, and in fact v11 entirely misses the opportunity to apply partition constraints when a partition is accessed directly (rather than indirectly from its parent). In HEAD, establish the principle that enable_partition_pruning controls partition pruning and nothing else. When accessing a partition via its parent, we do partition pruning (if enabled by enable_partition_pruning) and then there is no need to consider partition constraints in the constraint_exclusion logic. When accessing a partition directly, its partition constraints are applied by the constraint_exclusion logic, only if constraint_exclusion = on. In v11, we can't have such a clean division of these GUCs' effects, partly because we don't want to break compatibility too much in a released branch, and partly because the clean coding requires inheritance_planner to have applied partition pruning to a partitioned target table, which it doesn't in v11. However, we can tweak things enough to cover the missed case, which seems like a good idea since it's potentially a performance regression from v10. This patch keeps v11's previous behavior in which enable_partition_pruning overrides constraint_exclusion for an inherited target table, though. In HEAD, also teach relation_excluded_by_constraints that it's okay to use inheritable constraints when trying to prune a traditional inheritance tree. This might not be thought worthy of effort given that that feature is semi-deprecated now, but we have enough infrastructure that it only takes a couple more lines of code to do it correctly. Amit Langote and Tom Lane Discussion: https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e03ff739695cb731956763355e8e0f38c6905008 - Fix reindexing of pg_class indexes some more. Commits 3dbb317d3 et al failed under CLOBBER_CACHE_ALWAYS testing. Investigation showed that to reindex pg_class_oid_index, we must suppress accesses to the index (via SetReindexProcessing) before we call RelationSetNewRelfilenode, or at least before we do CommandCounterIncrement therein; otherwise, relcache reloads happening within the CCI may try to fetch pg_class rows using the index's new relfilenode value, which is as yet an empty file. Of course, the point of 3dbb317d3 was that that ordering didn't work either, because then RelationSetNewRelfilenode's own update of the index's pg_class row cannot access the index, should it need to. There are various ways we might have got around that, but Andres Freund came up with a brilliant solution: for a mapped index, we can really just skip the pg_class update altogether. The only fields it was actually changing were relpages etc, but it was just setting them to zeroes which is useless make-work. (Correct new values will be installed at the end of index build.) All pg_class indexes are mapped and probably always will be, so this eliminates the problem by removing work rather than adding it, always a pleasant outcome. Having taught RelationSetNewRelfilenode to do it that way, we can revert the code reordering in reindex_index. (But I left the moved setup code where it was; there seems no reason why it has to run without use of the old index. If you're trying to fix a busted pg_class index, you'll have had to disable system index use altogether to get this far.) Moreover, this means we don't need RelationSetIndexList at all, because reindex_relation's hacking to make "REINDEX TABLE pg_class" work is likewise now unnecessary. We'll leave that code in place in the back branches, but a follow-on patch will remove it in HEAD. In passing, do some minor cleanup for commit 5c1560606 (in HEAD only), notably removing a duplicate newrnode assignment. Patch by me, using a core idea due to Andres Freund. Back-patch to all supported branches, as 3dbb317d3 was. Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f912d7dec29341d55315fccef8dc3fdfd068c6e3 - Remove RelationSetIndexList(). In the wake of commit f912d7dec, RelationSetIndexList isn't used any more. It was always a horrid wart, so getting rid of it is very nice. We can also convert rd_indexvalid back to a plain boolean. Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f884dca4959f64bd47e78102d1dadd2c77d49201 - Doc: remove obsolete comment about per-branch documentation. I should have removed this in a0b762626, but forgot. https://git.postgresql.org/pg/commitdiff/8309eae499d6782bfc5e81f4d1cfcbf8e3fc8f5d - Fix style violations in syscache lookups. Project style is to check the success of SearchSysCacheN and friends by applying HeapTupleIsValid to the result. A tiny minority of calls creatively did it differently. Bring them into line with the rest. This is just cosmetic, since HeapTupleIsValid is indeed just a null check at the moment ... but that may not be true forever, and in any case it puts a mental burden on readers who may wonder why these call sites are not like the rest. Back-patch to v11 just to keep the branches in sync. (The bulk of these errors seem to have originated in v11 or v12, though a few are old.) Per searching to see if anyplace else had made the same error repaired in 62148c352. https://git.postgresql.org/pg/commitdiff/9691aa72e2a7fb146ac759e1f8a8b04962128cc0 - Add check for syscache lookup failure in update_relispartition(). Omitted in commit 05b38c7e6 (though it looks like the original blame belongs to 9e9befac4). A failure is admittedly unlikely, but if it did happen, SIGSEGV is not the approved method of reporting it. Per Coverity. Back-patch to v11 where the broken code originated. https://git.postgresql.org/pg/commitdiff/62148c3520b562e518f17134b22120bab0cb113b Noah Misch pushed: - Use preprocessor conditions compatible with Emacs indent. Emacs wrongly indented hundreds of subsequent lines. https://git.postgresql.org/pg/commitdiff/90e7f317735159116fdc3f90e287dd688b18a353 - Suppress compiler warning in non-SSL, non-assert builds. Jeff Janes, reviewed by Michael Paquier. Discussion: https://postgr.es/m/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/726cc4242a2f766c8280a72ef7c8418965d139c8 - MSVC: Build ~35% faster by calling dumpbin just once per directory. Peifeng Qiu Discussion: https://postgr.es/m/CABmtVJiKXQjast0dQD-8KAtfm8XmyYxo-4Dc7+M+fBr8JRTqkw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/34ff542a71f8e8e768b24d40548dec4be0c707c3 Peter Eisentraut pushed: - Fix potential catalog corruption with temporary identity columns. If a temporary table with an identity column and ON COMMIT DROP is created in a single-statement transaction (not useful, but allowed), it would leave the catalog corrupted. We need to add a CommandCounterIncrement() so that PreCommit_on_commit_actions() sees the created dependency between table and sequence and can clean it up. The analogous and more useful case of doing this in a transaction block already runs some CommandCounterIncrement() before it gets to the on-commit cleanup, so it wasn't a problem in practical use. Several locations for placing the new CommandCounterIncrement() call were discussed. This patch places it at the end of standard_ProcessUtility(). That would also help if other commands were to create catalog entries that some on-commit action would like to see. Bug: #15631 Reported-by: Serge Latyntsev <dnsl48@gmail.com> Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> https://git.postgresql.org/pg/commitdiff/cd3e27464cca40664c54fb8cd10454f979c1db4e Álvaro Herrera pushed: - Message fixes. https://git.postgresql.org/pg/commitdiff/ffbce803e646e254367a3f0670d8b64604badc50 - Widen tuple counter variables from long to int64. Mistake in ab0dfc961b6a; progress reporting would have wrapped around for indexes created with more than 2^31 tuples. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=WbNxc5ob5NJ9yqo2RMJ0q4HXDS30GVCobeCvC9A1L9A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9a83afecb7ec6e828b7dbef3133f3dd8b0b4dddb - Message style fixes. https://git.postgresql.org/pg/commitdiff/9f8b717a80c59e4a8e8091a8ff6c6f7666a69c33 - heap_prepare_freeze_tuple: Simplify coding. Commit d2599ecfcc74 introduced some contorted, confused code around: readers would think that it's possible for HeapTupleHeaderGetXmin return a non-frozen value for some frozen tuples, which would be disastrous. There's no actual bug, but it seems better to make it clearer. Per gripe from Tom Lane and Andres Freund. Discussion: https://postgr.es/m/30116.1555430496@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2bf372a4ae26337ee61cf7a82081cf4bed05182d Michaël Paquier pushed: - Fix some typos. Author: Daniel Gustafsson Discussion: https://postgr.es/m/42kEeWei6VxLGh12QbR08hiI5Pm-c3XgbK7qj393PSttEhVbnnQoFXHKzXjPRZLUpndWAfHIuZuUqGZBzyXadmEUCSqm9xphWur_I8vESMA=@yesql.se https://git.postgresql.org/pg/commitdiff/9c592896d9fc81d8def7b98c89a869588e76f0ea - Fix set of issues with memory-allocation system calls in frontend code. Like the backend, the frontend has wrappers on top of malloc() and such whose use is recommended. Particularly, it is possible to do memory allocation without issuing an error. Some binaries missed the use of those wrappers, so let's fix the gap for consistency. This also fixes two latent bugs: - In pg_dump/pg_dumpall when parsing an ACL item, on an out-of-memory error for strdup(), the code considered the failure as a ACL parsing problem instead of an actual OOM. - In pg_waldump, an OOM when building the target directory string would cause a crash. Author: Daniel Gustafsson Discussion: https://postgr.es/m/gY0y9xenfoBPc-Tufsr2Zg-MmkrJslm0Tw_CMg4p_j58-k_PXNC0klMdkKQkg61BkXC9_uWo-DcUzfxnHqpkpoR5jjVZrPHqKYikcHIiONhg=@yesql.se https://git.postgresql.org/pg/commitdiff/84e4570da9230d45022ef77f98b560f26eaf6916 Peter Geoghegan pushed: - Remove obsolete _bt_insert_parent() comment. Remove a comment that refers to a coding practice that was fully removed by commit a8b8f4db, which introduced MarkBufferDirty(). It looks like the comment was even obsolete before then, since it concerns write-ordering dependencies with synchronous buffer writes. https://git.postgresql.org/pg/commitdiff/9ee7414ed0435d8946d040eb523824f2d71e2418 - Fix nbtsort.c's page space accounting. Commit dd299df8189, which made heap TID a tiebreaker nbtree index column, introduced new rules on page space management to make suffix truncation safe. In general, suffix truncation needs to have a small amount of extra space available on the new left page when splitting a leaf page. This is needed in case it turns out that truncation cannot even "truncate away the heap TID column", resulting in a larger-than-firstright leaf high key with an explicit heap TID representation. Despite all this, CREATE INDEX/nbtsort.c did not account for the possible need for extra heap TID space on leaf pages when deciding whether or not a new item could fit on current page. This could lead to "failed to add item to the index page" errors when CREATE INDEX/nbtsort.c tried to finish off a leaf page that lacked space for a larger-than-firstright leaf high key (it only had space for firstright tuple, which was just short of what was needed following "truncation"). Several conditions needed to be met all at once for CREATE INDEX to fail. The problem was in the hard limit on what will fit on a page, which tends to be masked by the soft fillfactor-wise limit. The easiest way to recreate the problem seems to be a CREATE INDEX on a low cardinality text column, with tuples that are of non-uniform width, using a fillfactor of 100. To fix, bring nbtsort.c in line with nbtsplitloc.c, which already pessimistically assumes that all leaf page splits will have high keys that have a heap TID appended. Reported-By: Andreas Joseph Krogh Discussion: https://postgr.es/m/VisenaEmail.c5.3ee7fe277d514162.16a6d785bea@tc7-visena https://git.postgresql.org/pg/commitdiff/6dd86c269d5b9a176f6c9f67ea61cc17fef9d860 - Correct more obsolete nbtree page split comments. Commit 3f342839 corrected obsolete comments about buffer locks at the main _bt_insert_parent() call site, but missed similar obsolete comments above _bt_insert_parent() itself. Both sets of comments were rendered obsolete by commit 40dae7ec537, which made the nbtree page split algorithm more robust. Fix the comments that were missed the first time around now. In passing, refine a related _bt_insert_parent() comment about re-finding the parent page to insert new downlink. https://git.postgresql.org/pg/commitdiff/7b37f4b02e11813b3cd9f7086149ba962a91e03c Andres Freund pushed: - Fix several recently introduced issues around handling new relation forks. Most of these stem from d25f519107 "tableam: relation creation, VACUUM FULL/CLUSTER, SET TABLESPACE.". 1) To pass data to the relation_set_new_filenode() RelationSetNewRelfilenode() was made to update RelationData.rd_rel directly. That's not OK however, as it makes the relcache entries temporarily inconsistent. Which among other scenarios is a problem if a REINDEX targets an index on pg_class - the CatalogTupleUpdate() in RelationSetNewRelfilenode(). Presumably that was introduced because other places in the code do so - while those aren't "good practice" they don't appear to be actively buggy (e.g. because system tables may not be targeted). I (Andres) should have caught this while reviewing and signficantly evolving the code in that commit, mea culpa. Fix that by instead passing in the new RelFileNode as separate argument to relation_set_new_filenode() and rely on the relcache to update the catalog entry. Also revert that the RelationMapUpdateMap() call was changed to immediate, and undo some other more unnecessary changes. 2) Document that the relation_set_new_filenode cannot rely on the whole relcache entry to be valid. It might be worthwhile to refactor the code to never have to rely on that, but given the way heap_create() is currently coded, that'd be a large change. 3) ATExecSetTableSpace() shouldn't do FlushRelationBuffers() itself. A table AM might not use shared buffers at all. Move to index_copy_data() and heapam_relation_copy_data(). 4) heapam_relation_set_new_filenode() previously sometimes accessed rel->rd_rel->relpersistence rather than the `persistence` argument. Code movement mistake. 5) Previously heapam_relation_set_new_filenode() re-opened the smgr relation to create the init for, if necesary. Instead have RelationCreateStorage() return the SMgrRelation and use it to create the init fork. 6) Add a note about the danger of modifying the relcache directly to ATExecSetTableSpace() - it's currently not a bug because there's a check ERRORing for catalog tables. Regression tests and assertion improvements that together trigger the bug described in 1) will be added in a later commit, as there is a related bug on all branches. Reported-By: Michael Paquier Diagnosed-By: Tom Lane and Andres Freund Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz https://git.postgresql.org/pg/commitdiff/5c1560606dc4c73993fb07f0176b5ec6c515a1b1 - Fix potential assertion failure when reindexing a pg_class index. When reindexing individual indexes on pg_class it was possible to either trigger an assertion failure: TRAP: FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id))) That's because reindex_index() called SetReindexProcessing() - which enables an asserts ensuring no index insertions happen into the index - before calling RelationSetNewRelfilenode(). That not correct for indexes on pg_class, because RelationSetNewRelfilenode() updates the relevant pg_class row, which needs to update the indexes. The are two reasons this wasn't noticed earlier. Firstly the bug doesn't trigger when reindexing all of pg_class, as reindex_relation has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug only triggers when the the update to pg_class doesn't turn out to be a HOT update - otherwise there's no index insertion to trigger the bug. Most of the time there's enough space, making this bug hard to trigger. To fix, move RelationSetNewRelfilenode() to before the SetReindexProcessing() (and, together with some other code, to outside of the PG_TRY()). To make sure the error checking intended by SetReindexProcessing() is more robust, modify CatalogIndexInsert() to check ReindexIsProcessingIndex() even when the update is a HOT update. Also add a few regression tests for REINDEXing of system catalogs. The last two improvements would have prevented some of the issues fixed in 5c1560606dc4c from being introduced in the first place. Reported-By: Michael Paquier Diagnosed-By: Tom Lane and Andres Freund Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz Backpatch: 9.4-, the bug is present in all branches https://git.postgresql.org/pg/commitdiff/3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6 - docs: Fix small copy & paste mistake. Author: Justin Pryzby Discussion: https://postgr.es/m/20190418005115.r4mat75wvlski3ij@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/b06a354e381d30e13cef28904bb923896aa4719b - Improve code inferring length of bitmap for JITed tuple deforming. While discussing comment improvements (see next commit) by Justin Pryzby, Tom complained about a few details of the logic to infer the length of the NULL bitmap when building the JITed tuple deforming function. That bitmap allows to avoid checking the tuple header's natts, a check which often causes a pipeline stall Improvements: a) As long as missing columns aren't taken into account, we can continue to infer the length of the NULL bitmap from NOT NULL columns following it. Previously we stopped at the first missing column. It's unlikely to matter much in practice, but the alternative would have been to document why we stop. b) For robustness reasons it seems better to also check against attisdropped - RemoveAttributeById() sets attnotnull to false, but an additional check is trivial. c) Improve related comments Discussion: https://postgr.es/m/20637.1555957068@sss.pgh.pa.us Backpatch: - https://git.postgresql.org/pg/commitdiff/3a48005b0049d69b4376e6ae386479ae3d255a11 - Improve comment spelling and style in llvmjit_deform.c. Author: Justin Pryzby Discussion: https://postgr.es/m/20190408141828.GE10080@telsasoft.com https://postgr.es/m/20181127184133.GM10913@telsasoft.com https://git.postgresql.org/pg/commitdiff/a0b5bb6e026a3acf739843b744f3b14d4093450a - Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks. The tests turn out to cause deadlocks in some circumstances. Fairly reproducibly so with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE. Some of the deadlocks may be hard to fix without disproportionate measures, but others probably should be fixed - but not in 12. We discussed removing the new tests until we can fix the issues underlying the deadlocks, but results from buildfarm animal markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there might be a more severe, as of yet undiagnosed, issue (including on stable branches) with reindexing catalogs. The failure is: ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes Therefore it seems advisable to keep the tests. It's not certain that running the tests in isolation removes the risk of deadlocks. It's possible that additional locks are needed to protect against a concurrent auto-analyze or such. Per discussion with Tom Lane. Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us Backpatch: 9.4-, like 3dbb317d3 https://git.postgresql.org/pg/commitdiff/809c9b48f4bdd11dfc088f6d0b9a6c57936c32ca - Fix unused variable compiler warning in !debug builds. Introduced in 3dbb317d3. Fix by using the new local variable in more places. Reported-By: Bruce Momjian (off-list) Backpatch: 9.4-, like 3dbb317d3 https://git.postgresql.org/pg/commitdiff/4b40d40b30ae04ba524cd410f14e64ae4425a180 Bruce Momjian pushed: - doc: move "only" to a more appropriate place in the sentence. https://git.postgresql.org/pg/commitdiff/345473862571d5b2c63849f6472828bdc5b49320 - doc: improve PG 12 to_timestamp()/to_date() wording. https://git.postgresql.org/pg/commitdiff/ad23adc5a169b114f9ff325932cbf2ce1c5e69c1 - doc: clarify behavior of pg_upgrade's clone mode. Be more precise about the benefits of using clone mode. https://git.postgresql.org/pg/commitdiff/26950273dc27ec7775029cffe1140165f942325d Magnus Hagander pushed: - Fix union for pgstat message types. The message type for temp files and for checksum failures were missing from the union. Due to the coding style used there was no compiler error when this happend. So change the code to actively use the union thereby producing a compiler error if the same mistake happens again, suggested by Tom Lane. Author: Julien Rouhaud Reported-By: Tomas Vondra Discussion: https://postgr.es/m/20190430163328.zd4rrlnbvgaqlcdz@development https://git.postgresql.org/pg/commitdiff/659e53498c3c04e4f400323c02bef98fe8d13ec8 Robert Haas pushed: - Fix some problems with VACUUM (INDEX_CLEANUP FALSE). The new nleft_dead_tuples and nleft_dead_itemids fields are confusing and do not seem like the correct way forward. One of them is tested via an assertion that can fail, as it has already done on buildfarm member topminnow. Remove the assertion and the fields. Change the logic for the case where a tuple is not initially pruned by heap_page_prune but later diagnosed HEAPTUPLE_DEAD by HeapTupleSatisfiesVacuum. Previously, tupgone = true was set in that case, which leads to treating the tuple as one that will be removed. In a normal vacuum, that's OK, because we'll remove index entries for it and then the second heap pass will remove the tuple itself, but when index cleanup is disabled, those things don't happen, so we must instead treat it as a recently-dead tuple that we have voluntarily chosen to keep. Report and analysis by Tom Lane. This patch loosely based on one from Masahiko Sawada, but I changed most of it. https://git.postgresql.org/pg/commitdiff/dd69597988859c51131e0cbff3e30432db4259e1 == Pending Patches == Alexander Korotkov sent in two more revisions of a patch to improve error messages for JSONPATH. David Fetter sent in three more revisions of a patch to add \warn to psql. Anastasia Lubennikova sent in another revision of a patch to track splits correctly in the WAL optimization for GiST index creation. David Fetter and Fabien COELHO traded patches to show detailed table persistence in psql's \dt+. Paul Guo sent in another revision of a patch to skip copydir() if either src directory or dst directory is missing due to re-redoing create database but the tablespace is dropped. Justin Pryzby sent in another revision of a patch to improve the wording in to_timestamp()/to_date(). John Naylor and Amit Kapila traded patches to revert "Avoid the creation of the free space map for small heap relations". Amit Kapila and Dilip Kumar traded patches to allow undo actions to be applied on rollbacks and discard unwanted undo. Tomáš Vondra sent in a patch to fix a hang in walsender. Laurenz Albe sent in another revision of a patch to avoid canonicalizing dateranges with 'infinity' bounds. Antonin Houska sent in another revision of a patch to consolidate reading of XLOG pages into a single code path. Fabien COELHO sent in another revision of a patch for pgbench to add option to show actual builtin script code. Thomas Munro sent in two revisions of a patch to make file_fdw parallel-aware. Jeff Janes sent in a patch to fix a bug in the error checking of pg_upgrade --clone. Tom Lane sent in a patch to make AppendInvalidationMessageList actually append the current-commands list to the prior-cmds list. Justin Pryzby sent in another revision of a patch to make \d pg_toast.foo show its indices in psql. Dmitry Dolgov sent in another revision of a patch to speed up GROUP BY. Robert Haas sent in a patch to improve wraparound behavior. Peter Eisentraut sent in a patch to fix table lock levels for REINDEX INDEX CONCURRENTLY. Tomáš Vondra sent in a patch to account for memory used for BufFile during hash joins. Julien Rouhaud sent in a patch to fix a mistaken return code in vacuumdb when multiple jobs are used. Artur Zakirov sent in a patch to fix the explanation of FX in the to_timestamp. Peter Geoghegan sent in a patch to remove the nbtree half-dead internal page check. Tomáš Vondra sent in a patch to fix the way error messages are logged in extended statistics. Michaël Paquier sent in another revision of a patch to fix some inconsistent error message wording for REINDEX CONCURRENTLY.
pgsql-announce by date: