== PostgreSQL Weekly News - June 7, 2020 ==
| От | David Fetter |
|---|---|
| Тема | == PostgreSQL Weekly News - June 7, 2020 == |
| Дата | |
| Msg-id | 20200607224107.GA25833@fetter.org обсуждение исходный текст |
| Список | pgsql-announce |
== PostgreSQL Weekly News - June 7, 2020 == == PostgreSQL Product News == wal2mongo v1.0.6, a tool for replicating from PostgreSQL to MongoDB, released. https://github.com/HighgoSoftware/wal2mongo/releases/tag/v1.0.6 pgsodium 1.0.0, an extention which adds libsodium encryption to PostgreSQL, released. https://github.com/michelp/pgsodium PGEE, a fork of PostgreSQL by Cybertec, released. https://www.cybertec-postgresql.com/en/products/cybertec-postgresql-enterprise-edition/ pitrery 3.1, a set of Bash scripts to manage PITR backups for PostgreSQL, released. http://dalibo.github.io/pitrery/ == PostgreSQL Jobs for June == http://archives.postgresql.org/pgsql-jobs/2020-06/ == PostgreSQL Local == FOSS4G 2020, will take place in Calgary, Alberta, Canada August 24-29 2020. the Call for Papers is currently open at https://2020.foss4g.org/speakers/ https://2020.foss4g.org/ PGDay Ukraine will take place September 5th, 2020 in Lviv at the Bank Hotel. https://pgday.org.ua/ pgDay Israel 2020 will take place on September 10, 2020 in Tel Aviv. http://pgday.org.il/ PGDay Austria will take place September 18, 2020 at Schloss Schoenbrunn (Apothekertrakt) in Vienna. https://pgday.at/en/ PostgreSQL Conference Europe 2020 will be held on October 20-23, 2020 in Berlin, Germany. The CfP is open through July 31, 2020 at https://2020.pgconf.eu/callforpapers https://2020.pgconf.eu/ PG Day Russia will take place in Saint Petersburg on July 9, 2021. https://pgday.ru/en/2020/ == 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 == Andrew Dunstan pushed: - Make install-tests target work with vpath builds. Also add a top-level install-tests target. Backpatch to all live branches. Craig Ringer, tweaked by me. https://git.postgresql.org/pg/commitdiff/af4ea507c3d9217579a8d75fc17f4796a9bab0bb - Make ssl certificate for ssl_passphrase_callback test via Makefile. The recipe was previously given in comments in the module's test script, but now we have an explicit recipe in the Makefile. The now redundant comments in the script are removed. This recipe shouldn't be needed in normal use, as the certificate and key are in git and don't need to be regenerated. Discussion: https://postgr.es/m/ae8f21fc-95cb-c98a-f241-1936133f466f@2ndQuadrant.com https://git.postgresql.org/pg/commitdiff/b846091fd0a7a747933232016f0a52aa764398b8 Michaël Paquier pushed: - Fix crashes with currtid() and currtid2(). A relation that has no storage initializes rd_tableam to NULL, which caused those two functions to crash because of a pointer dereference. Note that in 11 and older versions, this has always failed with a confusing error "could not open file". These two functions are used by the Postgres ODBC driver, which requires them only when connecting to a backend strictly older than 8.1. When connected to 8.2 or a newer version, the driver uses a RETURNING clause instead whose support has been added in 8.2, so it should be possible to just remove both functions in the future. This is left as an issue to address later. While on it, add more regression tests for those functions as we never really had coverage for them, and for aggregates of TIDs. Reported-by: Jaime Casanova, via sqlsmith Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAJGNTeO93u-5APMga6WH41eTZ3Uee9f3s8dCpA-GSSqNs1b=Ug@mail.gmail.com Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/e786be5fcb257a09b05bd8e509c8d1b82e626352 - Fix use-after-release mistake in currtid() and currtid2() for views. This issue has been present since the introduction of this code as of a3519a2 from 2002, and has been found by buildfarm member prion that uses RELCACHE_FORCE_RELEASE via the tests introduced recently in e786be5. Discussion: https://postgr.es/m/20200601022055.GB4121@paquier.xyz Backpatch-through: 9.5 https://git.postgresql.org/pg/commitdiff/ce1c5b9ae87b6153d3f40a4f7806f2effef12363 - Fix instance of elog() called while holding a spinlock. This broke the project rule to not call any complex code while a spinlock is held. Issue introduced by b89e151. Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com Backpatch-through: 9.5 https://git.postgresql.org/pg/commitdiff/c1669fd5812a02daac58778e2708ede11edd36a3 - Fix comment in be-secure-openssl.c. Since 573bd08, hardcoded DH parameters have been moved to a different file, making the comment on top of load_dh_buffer() incorrect. Author: Daniel Gustafsson Discussion: https://postgr.es/m/D9492CCB-9A91-4181-A847-1779630BE2A7@yesql.se https://git.postgresql.org/pg/commitdiff/3fa44a30049826bfe2fd58eec0e8acabd5757411 - Preserve pg_index.indisreplident across REINDEX CONCURRENTLY. If the flag value is lost, logical decoding would work the same way as REPLICA IDENTITY NOTHING, meaning that no old tuple values would be included in the changes anymore produced by logical decoding. Author: Michael Paquier Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/20200603065340.GK89559@paquier.xyz Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/1127f0e392c757fc4fbbeffd7d0202bb02670e9c Peter Eisentraut pushed: - Use correct and consistent unit abbreviation. https://git.postgresql.org/pg/commitdiff/42181b1015b18e877e65be66ac5a2e90b731ac8b - psql: Clean up terminology in \dAp command. The preferred terminology has been support "function", not procedure, for some time, so change that over. The command stays \dAp, since \dAf is already something else. https://git.postgresql.org/pg/commitdiff/f5067049cde38cd0d6333a5e3bf1bed8d99e6f44 - OpenSSL 3.0.0 compatibility in tests. DES has been deprecated in OpenSSL 3.0.0 which makes loading keys encrypted with DES fail with "fetch failed". Solve by changing the cipher used to aes256 which has been supported since 1.0.1 (and is more realistic to use anyways). Note that the minimum supported OpenSSL version is 1.0.1 as of 7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, so this does not introduce any new version requirements. Author: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se https://git.postgresql.org/pg/commitdiff/f0d2c65f17cab8cfaf4d39f7f8e2254824cd4092 - Add missing source files to nls.mk. https://git.postgresql.org/pg/commitdiff/35b527428d6110dd0de585223a4783fe996a0020 - doc: Fix incorrect link target. https://git.postgresql.org/pg/commitdiff/c14a98032b17d514a195e4e76073ebc98a6521be - doc: Remove line breaks after <title>. This creates unnecessary rendering problem risks, and it's inconsistent and gets copied around. https://git.postgresql.org/pg/commitdiff/ab5b55505ec4bf08a9f93810e1bfada93bc63bb5 - doc: Clean up title case use. https://git.postgresql.org/pg/commitdiff/b3c2412e70f2be25ac70f7e9b2f12dbe4efd2a8b - doc: Trim trailing whitespace. https://git.postgresql.org/pg/commitdiff/b79cb8a919c2614c81ae7578b863b7f582a9baf2 - doc: Language review. https://git.postgresql.org/pg/commitdiff/4c6f70cd33ac395dea1acca7dabf4cb8556235e7 - doc: Fix up spacing around verbatim DocBook elements. https://git.postgresql.org/pg/commitdiff/9ac0a26210901a5869fd7ea83ab1c59489c1aeef - doc: Move options on man pages into more alphabetical order. https://git.postgresql.org/pg/commitdiff/b25da866152347109943f998b66b1a320a9de3e0 - Formatting and punctuation improvements in postgresql.conf.sample. https://git.postgresql.org/pg/commitdiff/f4c88ce1a20e8e944d74cb964926781d6ca4cb18 - doc: Fix man page whitespace issues. Whitespace between tags is significant, and in some cases it creates extra vertical space in man pages. The fix is either to remove some newlines or in some cases to reword slightly to avoid the awkward markup layout. https://git.postgresql.org/pg/commitdiff/a02b8bdd9878ae1d1ead87aabb673d60432500ea - Spelling adjustments. https://git.postgresql.org/pg/commitdiff/0fd2a79a637f9f96b9830524823df0454e962f96 - Fix message translatability. Two parts of the same message shouldn't be split across two function calls. https://git.postgresql.org/pg/commitdiff/1e8ada0c8a448891971faf71f48125439ee07023 - psql: Format \? output a little better. https://git.postgresql.org/pg/commitdiff/aa7927698acb813283d21aa6a47a67cd3c5a8b0c Amit Kapila pushed: - Doc: Update the documentation for spilled transaction statistics. Reported-by: Sawada Masahiko Author: Sawada Masahiko, Amit Kapila Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CA+fd4k4vNg7dRO5ECHdtQXXf1=Q4M98pfLW0dU7BKD8h79pkqA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e641b2a995abfa0dd7039863e2597feb3abf2b1e Fujii Masao pushed: - Don't call elog() while holding spinlock. Previously UpdateSpillStats() called elog(DEBUG2) while holding the spinlock even though the local variables that the elog() accesses don't need to be protected by the lock. Since spinlocks are intended for very short-term locks, they should not be used when calling elog(DEBUG2). So this commit moves that elog() out of spinlock period. Author: Kyotaro Horiguchi Reviewed-by: Amit Kapila and Fujii Masao Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com https://git.postgresql.org/pg/commitdiff/caa3c4242cf86322e2ed0c86199e6462a2c41565 - doc: Move wal_init_zero and wal_recycle descriptions to proper section. The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c, but previously their documents were located in "Replication"/"Sending Servers" section. This commit moves them to the proper section "Write Ahead Log"/"Settings". Back-patch to v12 where wal_init_zero and wal_recycle parameters were introduced. Author: Fujii Masao Discussion: https://postgr.es/m/b5190ab4-a169-6a42-0e49-aed0807c8976@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/43e592c706f8ce073d166f541687ad8f02dc22c0 Bruce Momjian pushed: - doc: PG 13 relnotes: fix link for grouping sets hash overflow. Use "guc-enable-groupingsets-hash-disk". Reported-by: TAKATSUKA Haruka Discussion: https://postgr.es/m/16468-7939d39f1786516c@postgresql.org Backpatch-through: master https://git.postgresql.org/pg/commitdiff/4d685f6d7b65fa1ca5afb5138e610cd08a3c1e12 Tom Lane pushed: - Don't call palloc() while holding a spinlock, either. Fix some more violations of the "only straight-line code inside a spinlock" rule. These are hazardous not only because they risk holding the lock for an excessively long time, but because it's possible for palloc to throw elog(ERROR), leaving a stuck spinlock behind. copy_replication_slot() had two separate places that did pallocs while holding a spinlock. We can make the code simpler and safer by copying the whole ReplicationSlot struct into a local variable while holding the spinlock, and then referencing that copy. (While that's arguably more cycles than we really need to spend holding the lock, the struct isn't all that big, and this way seems far more maintainable than copying fields piecemeal. Anyway this is surely much cheaper than a palloc.) That bug goes back to v12. InvalidateObsoleteReplicationSlots() not only did a palloc while holding a spinlock, but for extra sloppiness then leaked the memory --- probably for the lifetime of the checkpointer process, though I didn't try to verify that. Fortunately that silliness is new in HEAD. pg_get_replication_slots() had a cosmetic violation of the rule, in that it only assumed it's safe to call namecpy() while holding a spinlock. Still, that's a hazard waiting to bite somebody, and there were some other cosmetic coding-rule violations in the same function, so clean it up. I back-patched this as far as v10; the code exists before that but it looks different, and this didn't seem important enough to adapt the patch further back. Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com https://git.postgresql.org/pg/commitdiff/f88bd3139f3e2a557c086215c6b15d7f66bee845 - Reject "23:59:60.nnn" in datetime input. It's intentional that we don't allow values greater than 24 hours, while we do allow "24:00:00" as well as "23:59:60" as inputs. However, the range check was miscoded in such a way that it would accept "23:59:60.nnn" with a nonzero fraction. For time or timetz, the stored result would then be greater than "24:00:00" which would fail dump/reload, not to mention possibly confusing other operations. Fix by explicitly calculating the result and making sure it does not exceed 24 hours. (This calculation is redundant with what will happen later in tm2time or tm2timetz. Maybe someday somebody will find that annoying enough to justify refactoring to avoid the duplication; but that seems too invasive for a back-patched bug fix, and the cost is probably unmeasurable anyway.) Note that this change also rejects such input as the time portion of a timestamp(tz) value. Back-patch to v10. The bug is far older, but to change this pre-v10 we'd need to ensure that the logic behaves sanely with float timestamps, which is possibly nontrivial due to roundoff considerations. Doesn't really seem worth troubling with. Per report from Christoph Berg. Discussion: https://postgr.es/m/20200520125807.GB296739@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/a9632830bb05dc98ae24017cafc652e4a66d44a8 - Use query collation, not column's collation, while examining statistics. Commit 5e0928005 changed the planner so that, instead of blindly using DEFAULT_COLLATION_OID when invoking operators for selectivity estimation, it would use the collation of the column whose statistics we're considering. This was recognized as still being not quite the right thing, but it seemed like a good incremental improvement. However, shortly thereafter we introduced nondeterministic collations, and that creates cases where operators can fail if they're passed the wrong collation. We don't want planning to fail in cases where the query itself would work, so this means that we *must* use the query's collation when invoking operators for estimation purposes. The only real problem this creates is in ineq_histogram_selectivity, where the binary search might produce a garbage answer if we perform comparisons using a different collation than the column's histogram is ordered with. However, when the query's collation is significantly different from the column's default collation, the estimate we previously generated would be pretty irrelevant anyway; so it's not clear that this will result in noticeably worse estimates in practice. (A follow-on patch will improve this situation in HEAD, but it seems too invasive for back-patch.) The patch requires changing the signatures of mcv_selectivity and allied functions, which are exported and very possibly are used by extensions. In HEAD, I just did that, but an API/ABI break of this sort isn't acceptable in stable branches. Therefore, in v12 the patch introduces "mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes the old functions into wrappers that assume DEFAULT_COLLATION_OID should be used. That does not match the prior behavior, but it should avoid risk of failure in most cases. (In practice, I think most extension datatypes aren't collation-aware, so the change probably doesn't matter to them.) Per report from James Lucas. Back-patch to v12 where the problem was introduced. Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/044c99bc567ac5d44dff0af7aebb81737dc36a69 - Improve ineq_histogram_selectivity's behavior for non-default orderings. ineq_histogram_selectivity() can be invoked in situations where the ordering we care about is not that of the column's histogram. We could be considering some other collation, or even more drastically, the query operator might not agree at all with what was used to construct the histogram. (We'll get here for anything using scalarineqsel-based estimators, so that's quite likely to happen for extension operators.) Up to now we just ignored this issue and assumed we were dealing with an operator/collation whose sort order exactly matches the histogram, possibly resulting in junk estimates if the binary search gets confused. It's past time to improve that, since the use of nondefault collations is increasing. What we can do is verify that the given operator and collation match what's recorded in pg_statistic, and use the existing code only if so. When they don't match, instead execute the operator against each histogram entry, and take the fraction of successes as our selectivity estimate. This gives an estimate that is probably good to about 1/histogram_size, with no assumptions about ordering. (The quality of the estimate is likely to degrade near the ends of the value range, since the two orderings probably don't agree on what is an extremal value; but this is surely going to be more reliable than what we did before.) At some point we might further improve matters by storing more than one histogram calculated according to different orderings. But this code would still be good fallback logic when no matches exist, so that is not an argument for not doing this. While here, also improve get_variable_range() to deal more honestly with non-default collations. This isn't back-patchable, because it requires adding another argument to ineq_histogram_selectivity, and because it might have significant impact on the estimation results for extension operators relying on scalarineqsel --- mostly for the better, one hopes, but in any case destabilizing plan choices in back branches is best avoided. Per investigation of a report from James Lucas. Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0c882e52a8660114234a0c4a29db919bb727e552 - Doc: remove annotations about multi-row output of set-returning functions. I thought this added clarity, or at least was consistent with the way these entries looked before v13 ... but apparently I'm in the minority. Discussion: https://postgr.es/m/CAFj8pRAXuetiHUfs73zjsJD6B78FWcUsBS-j23sdCMFXkgx5Fg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ec5d6fc4ae8c75391d99993cd030a8733733747d - Rethink definition of cancel.c's CancelRequested flag. As it stands, this flag is only set when we've successfully sent a cancel request, not if we get SIGINT and then fail to send a cancel. However, for almost all callers, that's the Wrong Thing: we'd prefer to abort processing after control-C even if no cancel could be sent. As an example, since commit 1d468b9ad "pgbench -i" fails to give up sending COPY data even after control-C, if the postmaster has been stopped, which is clearly not what the code intends and not what anyone would want. (The fact that it keeps going at all is the fault of a separate bug in libpq, but not letting CancelRequested become set is clearly not what we want here.) The sole exception, as far as I can find, is that scripts_parallel.c's ParallelSlotsGetIdle tries to consume a query result after issuing a cancel, which of course might not terminate quickly if no cancel happened. But that behavior was poorly thought out too. No user of ParallelSlotsGetIdle tries to continue processing after a cancel, so there is really no point in trying to clear the connection's state. Moreover this has the same defect as for other users of cancel.c, that if the cancel request fails for some reason then we end up with control-C being completely ignored. (On top of that, select_loop failed to distinguish clearly between SIGINT and other reasons for select(2) failing, which means that it's possible that the existing code would think that a cancel has been sent when it hasn't.) Hence, redefine CancelRequested as simply meaning that SIGINT was received. We could add a second flag with the other meaning, but in the absence of any compelling argument why such a flag is needed, I think it would just offer an opportunity for future callers to get it wrong. Also remove the consumeQueryResult call in ParallelSlotsGetIdle's failure exit. In passing, simplify the API of select_loop. It would now be possible to re-unify psql's cancel_pressed with CancelRequested, partly undoing 5d43c3c54. But I'm not really convinced that that's worth the trouble, so I left psql alone, other than fixing a misleading comment. This code is new in v13 (cf a4fd3aa71), so no need for back-patch. Per investigation of a complaint from Andres Freund. Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/92f33bb7afd373ed562e23077c14831944d1b0d4 - Try to read data from the socket in pqSendSome's write_failed paths. Even when we've concluded that we have a hard write failure on the socket, we should continue to try to read data. This gives us an opportunity to collect any final error message that the backend might have sent before closing the connection; moreover it is the job of pqReadData not pqSendSome to close the socket once EOF is detected. Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect data in the case where we'd already set write_failed. The problem was masked for ordinary query operations (which really only make one write attempt anyway), but COPY to the server would continue to send data indefinitely after a mid-COPY connection loss. Hence, add pqReadData calls into the paths where pqSendSome drops data because of write_failed. If we've lost the connection, this will eventually result in closing the socket and setting CONNECTION_BAD, which will cause PQputline and siblings to report failure, allowing the application to terminate the COPY sooner. (Basically this restores what happened before 1f39a1c06.) There are related issues that this does not solve; for example, if the backend sends an error but doesn't drop the connection, we did and still will keep pumping COPY data as long as the application sends it. Fixing that will require application-visible behavior changes though, and anyway it's an ancient behavior that we've had few complaints about. For now I'm just trying to fix the regression from 1f39a1c06. Per a complaint from Andres Freund. Back-patch into v12 where 1f39a1c06 came in. Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/7247e243a803044a79a2828ced51b05765e049a0 Joe Conway pushed: - Add unlikely() to CHECK_FOR_INTERRUPTS(). Add the unlikely() branch hint macro to CHECK_FOR_INTERRUPTS(). Backpatch to REL_10_STABLE where we first started using unlikely(). Discussion: https://www.postgresql.org/message-id/flat/8692553c-7fe8-17d9-cbc1-7cddb758f4c6%40joeconway.com https://git.postgresql.org/pg/commitdiff/87fb04af1e705b615ac01feba958f841ea4a71a6 Noah Misch pushed: - Refresh function name in CRC-associated Valgrind suppressions. Back-patch to 9.5, where commit 4f700bcd20c087f60346cb8aefd0e269be8e2157 first appeared. Reviewed by Tom Lane. Reported by Andrew Dunstan. Discussion: https://postgr.es/m/4dfabec2-a3ad-0546-2d62-f816c97edd0c@2ndQuadrant.com https://git.postgresql.org/pg/commitdiff/26056b3ba84d6cb51eea5d6c83fefae19919a56b Magnus Hagander pushed: - Fix reference to wrong view in release notes. The estimate of total backup size effects the view pg_stat_progress_basebackup, not pg_stat_progress_analyze. https://git.postgresql.org/pg/commitdiff/6e2f11b631b712d691aecdbbcaa7a75b391c1e98 Thomas Munro pushed: - Doc: Clean up references to obsolete OS versions. Remove obsolete instructions for old operating system versions, and update the text to reflect the defaults on modern systems. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Magnus Hagander <magnus@hagander.net> Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/c8be915aa9fcc4c0cba563ddbb2e5af7a2dadd12 Jeff Davis pushed: - Fix platform-specific performance regression in logtape.c. Commit 24d85952 made a change that indirectly caused a performance regression by triggering a change in the way GCC optimizes memcpy() on some platforms. The behavior seemed to contradict a GCC document, so I filed a report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 This patch implements a narrow workaround which eliminates the regression I observed. The workaround is benign enough that it seems unlikely to cause a different regression on another platform. Discussion: https://postgr.es/m/99b2eab335c1592c925d8143979c8e9e81e1575f.camel@j-davis.com https://git.postgresql.org/pg/commitdiff/1fbb6c93df30801f83c6804ab7befde3cdefe677 == Pending Patches == Nathan Bossart sent in another revision of a patch to add MAIN_RELATION_CLEANUP and TOAST_TABLE_CLEANUP options to VACUUM. Kyotaro HORIGUCHI sent in another revision of a patch to make the stats collector use shared memory instead of files for temporary storage. Mark Dilger sent in a patch to remove a duplicate check for RELKIND_PARTITIONED_INDEX. Andrey V. Lepikhov sent in two revisions of a patch to speed up COPY FROM into tables with foreign partitions. Martín Marqués and Kyotaro HORIGUCHI traded patches to add read access for pg_monitor to the pg_replication_origin_status view. Amit Langote sent in another revision of a patch to make updates and deletes to inheritance trees scale better. Mark Dilger sent in two more revisions of a patch to implement cmdstats, a subsystem for tracking the number of times a type of command has been run in a database cluster, since startup or since the last time the counts were reset, whichever is newer. Michaël Paquier sent in another revision of a patch to fix a bug that manifested as SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762. Bertrand Drouvot sent in two revisions of a patch to add a pg_lwlock_blocking_pid() function. Fujii Masao sent in another revision of a patch to drop non-fast promotion. Andres Freund sent in another revision of a patch to make pq_begintypsend and friends more efficient. Mark Dilger sent in a patch to rename relkind as objtype where appropriate. The previous overloading was confusing. Mikhail Titov sent in a patch to add a leading minus for negative time intervals in ISO 8601 format. Vigneshwaran C sent in another revision of a patch to enable the COPY FROM command to process data from files or STDIN to a table in parallel. Michaël Paquier sent in a patch to remove currtid() and currtid2(), and move heap_get_latest_tid() within the heap AM handler. Kyotaro HORIGUCHI sent in another revision of a patch to allow wait event sets to be registered to resource owners, add infrastructure for asynchronous execution, and use same to add asynchronous operations to the PostgreSQL FDW. Atsushi Torikoshi sent in another revision of a patch to expose the counters of plancache to pg_prepared_statements. Lee Dong Wook sent in two revisions of a patch to add an example and link for --encoding option of pg_dump. Thomas Munro sent in a patch to redesign the error handling in buffile.c. Masahiko Sawada sent in another revision of a patch to make 2PC work on foreign servers. Pavel Stěhule sent in another revision of a patch to add a string_to_table() function. Chen Hujaun sent in a PoC patch to enable page compression for OLTP workloads. Antonin Houska sent in another revision of a patch to make referential integrity checks more efficient. Peter Eisentraut sent in a patch to make more use of RELKIND_HAS_STORAGE(). Alexey Bashtanov sent in a patch to improve planner cost estimations for alternative subplans. Amit Kapila sent in another revision of a patch to immediately WAL-log the subtransaction and top-level XID association. Jeff Davis sent in a patch to fix a performance regression related to FORTIFY_SOURCE. Fabien COELHO sent in another revision of a patch to psql to make it show all results of all queries sent. Justin Pryzby sent in a patch to make it possible to use CREATE INDEX CONCURRENTLY on a partitioned table.
В списке pgsql-announce по дате отправления: