== PostgreSQL Weekly News - June 7, 2020 ==

== 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(at)fetter(dot)org(dot)

== 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(at)yesql(dot)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(at)sss(dot)pgh(dot)pa(dot)us> Reviewed-by:
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> Reviewed-by: Magnus
Hagander <magnus(at)hagander(dot)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.