== PostgreSQL Weekly News - January 07 2018 ==

== PostgreSQL Weekly News - January 07 2018 ==

== PostgreSQL Product News ==

Buildfarm 6.1 software, a continuous integration system for the PostgreSQL
project, released.
https://buildfarm.postgresql.org/downloads/releases/build-farm-6_1.tgz

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2018-01/

== PostgreSQL Local ==

FOSDEM PGDay 2018, a one day conference held before the main FOSDEM event will
be held in Brussels, Belgium, on Feb 2nd, 2018.
https://2018.fosdempgday.org/

Prague PostgreSQL Developer Day 2018 (P2D2 2018) is a two-day
conference that will be held on February 14-15 2018 in Prague, Czech Republic.
http://www.p2d2.cz/

PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL(at)SCaLE is a two day, two track event which takes place on
March 8-9, 2018, at Pasadena Convention Center, as part of SCaLE 16X.
http://www.socallinuxexpo.org/scale/16x/cfp

Nordic PGDay 2018 will be held in Oslo, Norway, at the Radisson Blu Hotel
Nydalen, on March 13, 2018. The CfP is open through December 31, 2017 at
https://2018.nordicpgday.org/cfp/

pgDay Paris 2018 will be held in Paris, France at the Espace Saint-Martin, on
March 15 2018. The CfP is open until December 31, 2017.
http://2018.pgday.paris/callforpapers/

PGConf APAC 2018 will be held in Singapore March 22-23, 2018.
http://2018.pgconfapac.org/

The German-speaking PostgreSQL Conference 2018 will take place on April 13th,
2018 in Berlin. The CfP is open until January 09, 2018 at
http://2018.pgconf.de/de/callforpapers.html and the conference site is at
http://2018.pgconf.de/

PGConfNepal 2018 will be held May 4-5, 2018 at Kathmandu University, Dhulikhel,
Nepal. The CfP is open until 2018-02-01 at
https://postgresconf.org/conferences/Nepal2018/program/proposals
https://postgresconf.org/conferences/Nepal2018

PGCon 2018 will take place in Ottawa on May 29 - June 1, 2018. The CFP is open
until January 19, 2018 at https://www.pgcon.org/2018/papers.php
https://www.pgcon.org/2018/

PGConf.Brazil 2018 will take place in São Paulo, Brazil on August 3-4 2018. The
CfP will open soon.
http://pgconf.com.br

== 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 EST5EDT. Please send English
language ones to david(at)fetter(dot)org, German language to pwn(at)pgug(dot)de, Italian
language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Merge coding of return/exit/continue cases in plpgsql's loop statements.
plpgsql's five different loop control statements contained three distinct
implementations of the same (or what ought to be the same, at least) logic for
handling return/exit/continue result codes from their child statements. At
best, that's trouble waiting to happen, and there seems no very good reason
for the coding to be so different. Refactor so that all the common logic is
expressed in a single macro. Discussion:
https://postgr.es/m/26314.1514670401@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/3e724aac74e8325fe48dac8a30c2a7974eff7a14

- Improve regression tests' code coverage for plpgsql control structures. I
noticed that our code coverage report showed considerable deficiency in test
coverage for PL/pgSQL control statements. Notably, both exec_stmt_block and
most of the loop control statements had very poor coverage of handling of
return/exit/continue result codes from their child statements; and
exec_stmt_fori was seriously lacking in feature coverage, having no test that
exercised its BY or REVERSE features, nor verification that its overflow
defenses work. Now that we have some infrastructure for plpgsql-specific test
scripts, the natural thing to do is make a new script rather than further
extend plpgsql.sql. So I created a new script plpgsql_control.sql with the
charter to test plpgsql control structures, and moved a few existing tests
there because they fell entirely under that charter. I then added new test
cases that exercise the bits of code complained of above. Of the five kinds
of loop statements, only exec_stmt_while's result code handling is fully
exercised by these tests. That would be a deficiency as things stand, but a
follow-on commit will merge the loop statements' result code handling into one
implementation. So testing each usage of that implementation separately seems
redundant. In passing, also add a couple test cases to plpgsql.sql to more
fully exercise plpgsql's code related to expanded arrays --- I had thought
that area was sufficiently covered already, but the coverage report showed a
couple of un-executed code paths. Discussion:
https://postgr.es/m/26314.1514670401@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/dd2243f2ade43bcad8e615e6cf4286be250e374a

- Ensure proper alignment of tuples in HashMemoryChunkData buffers. The
previous coding relied (without any documentation) on the data[] member of
HashMemoryChunkData being at a MAXALIGN'ed offset. If it was not, the tuples
would not be maxaligned either, leading to failures on alignment-picky
machines. While there seems to be no live bug on any platform we support,
this is clearly pretty fragile: any addition to or rearrangement of the fields
in HashMemoryChunkData could break it. Let's remove the hazard by getting rid
of the data[] member and instead using pointer arithmetic with an explicitly
maxalign'ed offset. Discussion:
https://postgr.es/m/14483.1514938129@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/5dc692f78d3bee1e86d095a9e8d9242b44f78b01

- Teach eval_const_expressions() to handle some more cases. Add some
infrastructure (mostly macros) to make it easier to write typical cases for
constant-expression simplification. Add simplification processing for
ArrayRef, RowExpr, and ScalarArrayOpExpr node types, which formerly went
unsimplified even if all their inputs were constants. Also teach it to
simplify FieldSelect from a composite constant. Make use of the new
infrastructure to reduce the amount of code needed for the existing ArrayExpr
and ArrayCoerceExpr cases. One existing test case changes output as a result
of the fact that RowExpr can now be folded to a constant. All the new code is
exercised by existing test cases according to gcov, so I feel no need to add
additional tests. Tom Lane, reviewed by Dmitry Dolgov Discussion:
https://postgr.es/m/3be3b82c-e29c-b674-2163-bf47d98817b1@iki.fi
https://git.postgresql.org/pg/commitdiff/3decd150a2d5a8f8d43010dd0c207746ba946303

- Fix some minor errors in new PHJ code. Correct
ExecParallelHashTuplePrealloc's estimate of whether the space_allowed limit is
exceeded. Be more consistent about tuples that are exactly
HASH_CHUNK_THRESHOLD in size (they're "small", not "large"). Neither of these
things explain the current buildfarm unhappiness, but they're still bugs.
Thomas Munro, per gripe by me Discussion:
https://postgr.es/m/CAEepm=34PDuR69kfYVhmZPgMdy8pSA-MYbpesEN1SR+2oj3Y+w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/6fcde24063047c1195d023dfa08309302987cdcf

- Clean up tupdesc.c for recent changes. TupleDescCopy needs to have the same
effects as CreateTupleDescCopy in that, since it doesn't copy constraints, it
should clear the per-attribute fields associated with them. Oversight in
commit cc5f81366. Since TupleDescCopy has already established the presumption
that it can just flat-copy the entire attribute array in one go, propagate
that approach into CreateTupleDescCopy and CreateTupleDescCopyConstr. (I'm
suspicious that this would lead to valgrind complaints if we had any trailing
padding in the struct, but we do not, and anyway fixing that seems like a job
for a separate commit.) Add some better comments. Thomas Munro, reviewed by
Vik Fearing, some additional hacking by me Discussion:
https://postgr.es/m/CAEepm=0NvOGZ8B6GbQyQe2C_c2m3LKJ9w=8OMBaYRLgZ_Gw6Nw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/47c6772eb7222dbfa200db4bbeba8002b96b7976

- Tweak parallel hash join test case in hopes of improving stability. This
seems to make things better on gaur, let's see what the rest of the buildfarm
thinks. Thomas Munro Discussion:
https://postgr.es/m/CAEepm=1uuT8iJxMEsR=jL+3zEi87DB2v0+0H9o_rUXXCZPZT3A@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/934c7986f4a0a6a3b606301d84b784a27c0c324b

- Fix incorrect computations of length of null bitmap in pageinspect. Instead
of using our standard macro for this calculation, this code did it itself ...
and got it wrong, leading to incorrect display of the null bitmap in some
cases. Noted and fixed by Maksim Milyutin. In passing, remove a uselessly
duplicative error check. Errors were introduced in commit d6061f83a;
back-patch to 9.6 where that came in. Maksim Milyutin, reviewed by Andrey
Borodin Discussion:
https://postgr.es/m/ec295792-a69f-350f-6287-25a20e8f31d5@gmail.com
https://git.postgresql.org/pg/commitdiff/39cfe86195f0b5cbc5fbe8d4e3aa6e2b0e322d0b

- Fix new test case to not be endian-dependent. Per buildfarm. Discussion:
https://postgr.es/m/ec295792-a69f-350f-6287-25a20e8f31d5@gmail.com
https://git.postgresql.org/pg/commitdiff/18869e202b74f36d504c5c3c7d9db9c186039eba

- Rewrite ConditionVariableBroadcast() to avoid live-lock. The original
implementation of ConditionVariableBroadcast was, per its self-description,
"the dumbest way possible". Thomas Munro found out it was a bit too dumb. An
awakened process may immediately re-queue itself, if the specific condition
it's waiting for is not yet satisfied. If this happens before
ConditionVariableBroadcast is able to see the wait queue as empty, then
ConditionVariableBroadcast will re-awaken the same process, repeating the
cycle. Given unlucky timing this back-and-forth can repeat indefinitely;
loops lasting thousands of seconds have been seen in testing. To fix, add our
own process to the end of the wait queue to serve as a sentinel, and exit the
broadcast loop once our process is not there anymore. There are various
special considerations described in the comments, the principal disadvantage
being that wakers can no longer be sure whether they awakened a real waiter or
just a sentinel. But in practice nobody pays attention to the result of
ConditionVariableSignal or ConditionVariableBroadcast anyway, so that problem
seems hypothetical. Back-patch to v10 where condition_variable.c was
introduced. Tom Lane and Thomas Munro Discussion:
https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/aced5a92bf46532466417ab485bc94006cf60d91

- Reorder steps in ConditionVariablePrepareToSleep for more safety. In the
admittedly-very-unlikely case that AddWaitEventToSet fails,
ConditionVariablePrepareToSleep would error out after already having set
cv_sleep_target, which is probably bad, and after having already set
cv_wait_event_set, which is very bad. Transaction abort might or might not
clean up cv_sleep_target properly; but there is nothing that would be aware
that the WaitEventSet wasn't fully constructed, so that all future condition
variable sleeps would be broken. We can easily guard against these hazards
with slight restructuring. Back-patch to v10 where condition_variable.c was
introduced. Discussion:
https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/3cac0ec85992829c160bdd8a370dd4676d42f58c

- Remove return values of ConditionVariableSignal/Broadcast. In the wake of
commit aced5a92b, the semantics of these results are a bit squishy: we can
tell whether we signaled some other process(es), but we do not know which ones
were real waiters versus mere sentinels for ConditionVariableBroadcast
operations. It does not help much that ConditionVariableBroadcast will
attempt to pass on the signal to the next real waiter, because (a) there might
not be one, and (b) that will only happen awhile later, anyway. So these
results could overstate how much effect the calls really had. However, no
existing caller of either function pays any attention to its result value, so
it seems reasonable to just define that as a required property of a correct
algorithm. To encourage correctness and save some tiny number of cycles,
change both functions to return void. Patch by me, per an observation by
Thomas Munro. No back-patch, since if any third parties happen to be using
these functions, they might not appreciate an API break in a minor release.
Discussion:
https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/ccf312a4488ab8bb38dfd87168bf8915045d1a82

Noah Misch pushed:

- In tests, await an LSN no later than the recovery target. Otherwise, the test
fails with "Timed out while waiting for standby to catch up". This happened
rarely, perhaps only when autovacuum wrote WAL between our choosing the
recovery target and choosing the LSN to await. Commit
b26f7fa6ae2b4e5d64525b3d5bc66a0ddccd9e24 fixed one case of this. Fix two
more. Back-patch to 9.6, which introduced the affected test. Discussion:
https://postgr.es/m/20180101055227.GA2952815@rfd.leadboat.com
https://git.postgresql.org/pg/commitdiff/6078770c1a6c247bb74742cb1b82733cce8afcab

Andres Freund pushed:

- Fix EXPLAIN ANALYZE output for Parallel Hash. In a race case, EXPLAIN ANALYZE
could fail to display correct nbatch and size information. Refactor so that
participants report only on batches they worked on rather than trying to
report on all of them, and teach explain.c to consider the HashInstrumentation
object from all participants instead of picking the first one it can find.
This should fix an occasional build farm failure in the "join" regression
test. Author: Thomas Munro Reviewed-By: Andres Freund Discussion:
https://postgr.es/m/30219.1514428346%40sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/93ea78b17c4743c2b63edb5998fb5796ae57e289

- Simplify representation of aggregate transition values a bit. Previously
aggregate transition values for hash and other forms of aggregation (i.e. sort
and no group by) were represented differently. Hash based aggregation used a
grouping set indexed array pointing to an array of transition values, whereas
other forms of aggregation used one flattened array with the index being
computed out of grouping set and transition offsets. That made upcoming
changes hard, so represent both as grouping set indexed array of per-group
data. As a nice side-effect this also makes aggregation slightly faster,
because computing offsets with `transno + (setno * numTrans)` turns out not to
be that cheap (too big for x86 lea for example). Author: Andres Freund
Discussion:
https://postgr.es/m/20171128003121.nmxbm2ounxzb6n2t@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/f9ccf92e16fc4d831d324c7f7ef347a0acdaef0a

- Rename pg_rewind's copy_file_range() to avoid conflict with new linux syscall.
Upcoming versions of glibc will contain copy_file_range(2), a wrapper around a
new linux syscall for in-kernel copying of data ranges. This conflicts with
pg_rewinds function of the same name. Therefore rename pg_rewinds version. As
our version isn't a generic copying facility we decided to choose a rewind
specific function name. Per buildfarm animal caiman and subsequent discussion
with Tom Lane. Author: Andres Freund Discussion:
https://postgr.es/m/20180103033425.w7jkljth3e26sduc@alap3.anarazel.de
https://postgr.es/m/31122.1514951044@sss.pgh.pa.us Backpatch: 9.5-, where
pg_rewind was introduced
https://git.postgresql.org/pg/commitdiff/3e68686e2c55799234ecd020bd1621f913d65475

Peter Eisentraut pushed:

- Don't cast between GinNullCategory and bool. The original idea was that we
could use an isNull-style bool array directly as a GinNullCategory array.
However, the existing code already acknowledges that that doesn't really work,
because of the possibility that bool as currently defined can have arbitrary
bit patterns for true values. So it has to loop through the nullFlags array
to set each bool value to an acceptable value. But if we are looping through
the whole array anyway, we might as well build a proper GinNullCategory array
instead and abandon the type casting. That makes the code much safer in case
bool is ever changed to something else. Reviewed-by: Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/438036264a3b71eaf39b2d2eeca67237ed38ca51

- Define LDAPS_PORT if it's missing and disable implicit LDAPS on Windows. Some
versions of Windows don't define LDAPS_PORT. Also, Windows' ldap_sslinit() is
documented to use LDAPS even if you said secure=0 when the port number happens
to be 636 or 3269. Let's avoid using the port number to imply that you want
LDAPS, so that connection strings have the same meaning on Windows and Unix.
Author: Thomas Munro Discussion:
https://postgr.es/m/CAEepm%3D23B7GV4AUz3MYH1TKpTv030VHxD2Sn%2BLYWDv8d-qWxww%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/3ad2afc2e98fc85d5cf9529d84265b70acc0b13d

- Allow ldaps when using ldap authentication. While ldaptls=1 provides an RFC
4513 conforming way to do LDAP authentication with TLS encryption, there was
an earlier de facto standard way to do LDAP over SSL called LDAPS. Even
though it's not enshrined in a standard, it's still widely used and sometimes
required by organizations' network policies. There seems to be no reason not
to support it when available in the client library. Therefore, add support
when using OpenLDAP 2.4+ or Windows. It can be configured with
ldapscheme=ldaps or ldapurl=ldaps://... Add tests for both ways of requesting
LDAPS and a test for the pre-existing ldaptls=1. Modify the 001_auth.pl test
for "diagnostic messages", which was previously relying on the server
rejecting ldaptls=1. Author: Thomas Munro Reviewed-By: Peter Eisentraut
Discussion:
https://postgr.es/m/CAEepm=1s+pA-LZUjQ-9GQz0Z4rX_eK=DFXAF1nBQ+ROPimuOYQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/35c0754fadca8010955f6b10cb47af00bdbe1286

- Refactor channel binding code to fetch cbind_data only when necessary. As
things stand now, channel binding data is fetched from OpenSSL and saved into
the SCRAM exchange context for any SSL connection attempted for a SCRAM
authentication, resulting in data fetched but not used if no channel binding
is used or if a different channel binding type is used than what the data is
here for. Refactor the code in such a way that binding data is fetched from
the SSL stack only when a specific channel binding is used for both the
frontend and the backend. In order to achieve that, save the libpq connection
context directly in the SCRAM exchange state, and add a dependency to SSL in
the low-level SCRAM routines. This makes the interface in charge of
initializing the SCRAM context cleaner as all its data comes from either
PGconn* (for frontend) or Port* (for the backend). Author: Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/f3049a603a7950f313b33ab214f11563c66dc069

- Implement channel binding tls-server-end-point for SCRAM. This adds a second
standard channel binding type for SCRAM. It is mainly intended for
third-party clients that cannot implement tls-unique, for example JDBC.
Author: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/d3fb72ea6de58d285e278459bca9d7cdf7f6a38b

- Fix build with older OpenSSL versions. Apparently, X509_get_signature_nid()
is only in fairly new OpenSSL versions, so use the lower-level interface it is
built on instead.
https://git.postgresql.org/pg/commitdiff/ac3ff8b1d8f98da38c53a701e6397931080a39cf

- Add missing includes. <openssl/x509.h> is necessary to look into the X509
struct, used by ac3ff8b1d8f98da38c53a701e6397931080a39cf.
https://git.postgresql.org/pg/commitdiff/1834c1e432d22f9e186950c7dd8598958776e016

- Another attempt at fixing build with various OpenSSL versions. It seems we
can't easily work around the lack of X509_get_signature_nid(), so revert the
previous attempts and just disable the tls-server-end-point feature if we
don't have it.
https://git.postgresql.org/pg/commitdiff/054e8c6cdb7f4261869e49d3ed7705cca475182e

Bruce Momjian pushed:

- Update copyright for 2018. Backpatch-through: certain files through 9.3
https://git.postgresql.org/pg/commitdiff/9d4649ca49416111aee2c84b7e4441a0b7aa2fac

- pg_upgrade: simplify code layout in a few places. Backpatch-through: 9.4
(9.3 didn't need improving)
https://git.postgresql.org/pg/commitdiff/959ee6d267fb24e667fc64e9837a376e236e84a5

- pg_upgrade: revert part of patch for ease of translation. Revert part of
959ee6d267fb24e667fc64e9837a376e236e84a5 . Backpatch-through: 10
https://git.postgresql.org/pg/commitdiff/3e6f01fd7d9b01b17626a6bc38cf664354eede71

- pg_upgrade: remove C comment. Revert another part of
959ee6d267fb24e667fc64e9837a376e236e84a5 . Backpatch-through: 10
https://git.postgresql.org/pg/commitdiff/84a6f63e32dbefe3dc76cbe628fab6cbfc26141e

Álvaro Herrera pushed:

- Fix isolation test to be less timing-dependent. I did this by adding another
locking process, which makes the other two wait. This way the output should
be stable enough. Per buildfarm and Andres Freund Discussion:
https://postgr.es/m/20180103034445.t3utrtrnrevfsghm@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/2268e6afd59649d6bf6d114a19e9c492d59b43fc

- Make XactLockTableWait work for transactions that are not yet self-locked.
XactLockTableWait assumed that its xid argument has already added itself to
the lock table. That assumption led to another assumption that if locking the
xid has succeeded but the xid is reported as still in progress, then the input
xid must have been a subtransaction. These assumptions hold true for the
original uses of this code in locking related to on-disk tuples, but they
break down in logical replication slot snapshot building -- in particular,
when a standby snapshot logged contains an xid that's already in ProcArray but
not yet in the lock table. This leads to assertion failures that can be
reproduced all the way back to 9.4, when logical decoding was introduced. To
fix, change SubTransGetParent to SubTransGetTopmostTransaction which has a
slightly different API: it returns the argument Xid if there is no parent, and
it goes all the way to the top instead of moving up the levels one by one.
Also, to avoid busy-waiting, add a 1ms sleep to give the other process time to
register itself in the lock table. For consistency, change
ConditionalXactLockTableWait the same way. Author: Petr Jelínek Discussion:
https://postgr.es/m/1B3E32D8-FCF4-40B4-AEF9-5C0E3AC57969@postgrespro.ru
Reported-by: Konstantin Knizhnik Diagnosed-by: Stas Kelvich, Petr Jelínek
Reviewed-by: Andres Freund, Robert Haas
https://git.postgresql.org/pg/commitdiff/3c27944fb2141d8bd3942cb57e872174c6e1db97

- Revert "Fix isolation test to be less timing-dependent". This reverts commit
2268e6afd596. It turned out that inconsistency in the report is still
possible, so go back to the simpler formulation of the test and instead add an
alternate expected output. Discussion:
https://postgr.es/m/20180103193728.ysqpcp2xjnqpiep7@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/6c8be5962aea2eee8c366c01bbbcf5bf5ddf5294

- Fix typo. Author: Dagfinn Ilmari Mannsåker Discussion:
https://postgr.es/m/d8jefpk4jtd.fsf@dalvik.ping.uio.no
https://git.postgresql.org/pg/commitdiff/bab2969867fbba6a6d12730f36a20d13542aea5a

- Fix deadlock hazard in CREATE INDEX CONCURRENTLY. Multiple sessions doing
CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in
parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support
this case. In reality, one of the sessions would be aborted by a misterious
"deadlock detected" error. Jeff Janes diagnosed that this is because of
leftover snapshots used for system catalog scans -- this was broken by
8aa3e47510b9 keeping track of (registering) the catalog snapshot. To fix the
deadlocks, it's enough to de-register that snapshot prior to waiting.
Backpatch to 9.4, which introduced MVCC catalog scans. Include an
isolationtester spec that 8 out of 10 times reproduces the deadlock with the
unpatched code for me (Álvaro). Author: Jeff Janes Diagnosed-by: Jeff Janes
Reported-by: Jeremy Finzel Discussion:
https://postgr.es/m/CAMa1XUhHjCv8Qkx0WOr1Mpm_R4qxN26EibwCrj0Oor2YBUFUTg%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/54eff5311d7c8e3d309774713b91e78067d2ad42

- Fix failure to delete spill files of aborted transactions. Logical decoding's
reorderbuffer.c may spill transaction files to disk when transactions are
large. These are supposed to be removed when they become "too old" by xid;
but file removal requires the boundary LSNs of the transaction to be known.
The final_lsn is only set when we see the commit or abort record for the
transaction, but nothing sets the value for transactions that crash, so the
removal code misbehaves -- in assertion-enabled builds, it crashes by a failed
assertion. To fix, modify the final_lsn of transactions that don't have a
value set, to the LSN of the very latest change in the transaction. This
causes the spilled files to be removed appropriately. Author: Atsushi
Torikoshi Reviewed-by: Kyotaro HORIGUCHI, Craig Ringer, Masahiko Sawada
Discussion:
https://postgr.es/m/54e4e488-186b-a056-6628-50628e4e4ebc@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/df9f682c7bf81674b6ae3900fd0146f35df0ae2e

Andrew Dunstan pushed:

- Fix use of config-specific libraries for Windows OpenSSL. Commit 614350a3
allowed for an different builds of OpenSSL libraries on Windows, but ignored
the fact that the alternative builds don't have config-specific libraries.
This patch fixes the Solution file to ask for the correct libraries. per
offline discussions with Leonardo Cecchi and Marco Nenciarini, Backpatch to
all live branches.
https://git.postgresql.org/pg/commitdiff/99d5a3ffb9fe61a5a8b01a4759d93c627f018923

Robert Haas pushed:

- Code review for Parallel Append. Remove unnecessary #include mistakenly added
in execnodes.h. Fix mistake in comment in choose_next_subplan_for_leader.
Adjust row estimates in cost_append for a possibly-different parallel divisor.
Clamp row estimates in cost_append after operations that may not produce
integers. Amit Kapila, with cosmetic adjustments by me. Discussion:
http://postgr.es/m/CAA4eK1+qcbeai3coPpRW=GFCzFeLUsuY4T-AKHqMjxpEGZBPQg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/c759395617765c5bc21db149cf8c3df52f41ccff

- Simplify and encapsulate tuple routing support code. Instead of having
ExecSetupPartitionTupleRouting return multiple out parameters, have it return
a pointer to a structure containing all of those different things. Also,
provide and use a cleanup function, ExecCleanupTupleRouting, instead of
cleaning up all of the resources allocated by ExecSetupPartitionTupleRouting
individually. Amit Khandekar, reviewed by Amit Langote, David Rowley, and me
Discussion:
http://postgr.es/m/CAJ3gD9fWfxgKC+PfJZF3hkgAcNOy-LpfPxVYitDEXKHjeieWQQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/cc6337d2fed598d4b5ac54d9a62708182b83a81e

- Minor preparatory refactoring for UPDATE row movement. Generalize
is_partition_attr to has_partition_attrs and make it accessible from outside
tablecmds.c. Change map_partition_varattnos to clarify that it can be used
for mapping between any two relations in a partitioning hierarchy, not just
parent -> child. Amit Khandekar, reviewed by Amit Langote, David Rowley, and
me. Some comment changes by me. Discussion:
http://postgr.es/m/CAJ3gD9fWfxgKC+PfJZF3hkgAcNOy-LpfPxVYitDEXKHjeieWQQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/ef6087ee5fa84206dc24ba1339e229354b05cf2a

- Factor error generation out of ExecPartitionCheck. At present, we always
raise an ERROR if the partition constraint is violated, but a pending patch
for UPDATE tuple routing will consider instead moving the tuple to the correct
partition. Refactor to make that simpler. Amit Khandekar, reviewed by Amit
Langote, David Rowley, and me. Discussion:
http://postgr.es/m/CAJ3gD9cue54GbEzfV-61nyGpijvjZgCcghvLsB0_nL8Nm8HzCA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/19c47e7c820241e1befd975cb4411af7d43e1309

Simon Riggs pushed:

- Default monitoring roles - errata. 25fff40798fc4ac11a241bfd9ab0c45c085e2212
introduced default monitoring roles. Apply these corrections: * Allow access
to pg_stat_get_wal_senders() by role pg_read_all_stats * Correct comment in
pg_stat_get_wal_receiver() to show it is no longer superuser-only. Author:
Feike Steenbergen Reviewed-by: Michael Paquier Apply to HEAD, then later
backpatch to 10
https://git.postgresql.org/pg/commitdiff/6668a54eb8ef639a3182ae9e37e4e67982c44292

- Add TIMELINE to backup_label file. Allows new test to confirm timelines match
Author: Michael Paquier Reviewed-by: David Steele
https://git.postgresql.org/pg/commitdiff/6271fceb8a4f07dafe9d67dcf7e849b319bb2647

== Pending Patches ==

Jeevan Chalke sent in another revision of a patch to implement partition-wise
aggregation/grouping.

Fabien COELHO sent in two more revisions of a patch to add a --random-seed
option to pgbench.

Amit Kapila sent in another revision of a patch to ensure that parallel paths
include tlist cost.

Shubham Barai sent in another revision of a patch to implement predicate locking
in GIN indexes.

Marco Nenciarini sent in another revision of a patch to ensure that
session_replication_role = replica with TRUNCATE.

David Steele sent in another revision of a patch to implement a configurable
file mode mask.

Amit Khandekar sent in three more revisions of a patch to ensure that UPDATEs to
partitioned tables that would have the effect of moving tuples from one
partition to another actually do so.

Rushabh Lathia and Peter Geoghegan traded patches to add parallel tuplesort for
parallel B-Tree index creation.

Jesper Pedersen sent in a patch documenting how indexes automatically created on
partitioned tables are named.

Nikita Glukhov sent in two more revisions of a patch to implement SQL/JSON.

Tomas Vondra sent in another revision of a patch to implement controls on the
resources logical replication can consume.

Dagfinn Ilmari Mannsåker sent in a patch to remove a duplicate poly_ops row from
the SP-GiST opclass table.

Remi Colinet sent in another revision of a patch to make block and file size for
WAL and relations defined at cluster creation.

Haribabu Kommi sent in three more revisions of a patch to make
pg_stat_wal_receiver display connected hosts.

Haribabu Kommi sent in another revision of a patch to implement pluggable
storage.

Andrew Dunstan sent in two revisions of a patch to implement TZH and TZM format
specifiers in to_timestamp and friends.

Tomas Vondra sent in another revision of a patch to implement multivariate
histograms and MCV lists.

Fabien COELHO sent in another revision of a patch to add more functions and
operators to pgbench.

Thomas Munro sent in a patch to fix warnings about pg_attribute_always_inline.

Fabien COELHO sent in another revision of a patch to add \if support to pgbench.

Emre Hasegeli sent in another revision of a patch to improve the native
geometric types.

Dmitry Dolgov sent in another revision of a patch to implement generic type
subscripting and use same in arrays and JSONB.

Artur Zakirov sent in another revision of a patch to create a more flexible
configuration for full-text search.

Alexander Korotkov sent in another revision of a patch to fix some pg_trgm
word_similarity inconsistencies.

Tom Lane sent in another revision of a patch to improve OR conditions on joined
columns, which commonly occur in queries on star schemas.

Jing Wang sent in another revision of a patch to implement a 'prefer-read'
feature in libpq.

Alexander Korotkov sent in two more revisions of a patch to implement
incremental sort.

Álvaro Herrera sent in two more revisions of a patch to implement local indexes
for partitioned tables.

Vaishnavi Prabakaran sent in another revision of a patch to implement pipelining
batch support for libpq.

Haribabu Kommi sent in another revision of a patch to refactor database
attributes between pg_dump and pg_dumpall.

Peter Eisentraut sent in another revision of a patch to implement transaction
control in procedures.

Peter Eisentraut sent in a patch to fix ssl tests for when tls-server-end-point
is not supported.

Bruce Momjian sent in a patch to fix an invalid pg_upgrade error message during
live check.

Álvaro Herrera sent in another revision of a patch to allow indexes on
partitioned tables to be unique.

Marco Nenciarini sent in three more revisions of a patch to implement logical
decoding of TRUNCATE.

David Rowley sent in three more revisions of a patch to implement runtime
partition pruning.

David Rowley sent in another revision of a patch to remove useless DISTINCT
clauses where they're easily identified as such.

David Rowley sent in another revision of a patch to remove [Merge]Append nodes
which contain a single subpath.

Michaël Paquier sent in another revision of a patch to create backup history
files for backups taken from standbys.

Tom Lane sent in another revision of a patch to fix an Oracle-compatible instr
function in the documentation.

Pavel Stěhule sent in another revision of a patch to add some new checks to
PL/pgsql.

Simon Riggs sent in another revision of a patch to surface replication status
for logical replication.

Tomas Vondra sent in another revision of a patch to implement BRIN multi-range
indexes.

Artur Zakirov sent in another revision of a patch to enable sharing Ispell
dictionaries among backends.

Andrew Dunstan sent in another revision of a patch to implement JSONPATH.