PostgreSQL 13.0 (upcoming) commit log

commit   : e1ff780485ca9ff0d2db3cd716b63557fc6ae5e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 11:13:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 11:13:27 +0200    

Add a documentation appendix that explains the PG_COLOR and PG_COLORS  
environment variables.  
  
Discussion: https://www.postgresql.org/message-id/flat/bbdcce43-bd2e-5599-641b-9b44b9e0add4@2ndquadrant.com  

commit   : 9cedb1666051516c2763bb0ae4ace583cd26b141    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 09:25:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 09:25:40 +0200    

Put the temporary socket directory under TMPDIR, if that environment  
variable is set, instead of the hardcoded /tmp.  
  
This allows running the tests if there is no /tmp at all (for example  
on Windows, although running the tests with Unix-domain sockets is not  
enabled on Windows yet).  We also use TMPDIR everywhere else /tmp is  
hardcoded, so this makes the behavior consistent.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : b79911dc8c0dc3b864999b9a17333716d602c6a0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 08:56:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 08:56:41 +0200    

Change F181 to supported.  It requires that an embedded C program can  
be split across multiple files, which ECPG easily supports.  

commit   : 2dc16efedc767aec38368d215eb7695b87a054b5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 29 Mar 2020 19:36:20 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 29 Mar 2020 19:36:20 +1300    

b07642dbc added code to trigger autovacuums based on the number of  
inserts into a table. This seems to have caused some regression test  
results to destabilize. I suspect this is due to autovacuum triggering a  
vacuum sometime after the test's ANALYZE run and perhaps reltuples is  
ending up being set to a slightly different value as a result.  
  
Attempt to resolve this by running a VACUUM ANALYZE on the affected table  
instead of just ANALYZE. pg_class.reltuples will still get set to whatever  
ANALYZE chooses but we should no longer get the proceeding autovacuum  
overriding that.  
  
The overhead this adds to each test's runtime seems small enough not to  
worry about. I measure 3-4% on stats_ext and can't measure any change in  
partition_aggregate.  
  
I'm unable to recreate the issue locally, so this is a bit of a blind  
fix.  
  
Discussion: https://postgr.es/m/CAApHDvpWmpqYrKwwDQyeDq8dAyK7GMNaxDhrG69CkSuXoEg%2BVg%40mail.gmail.com  

commit   : a7b9d24e4e00048bf9d99b197996476dcf9492de    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 28 Mar 2020 20:25:03 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 28 Mar 2020 20:25:03 -0700    

Use IndexRelationGetNumberOfKeyAttributes() rather than  
IndexRelationGetNumberOfAttributes() when determining whether or not two  
index tuples are suitable for merging together into a single posting  
list tuple.  This is a little bit tidier.  It brings affected code in  
nbtdedup.c a little closer to similar, related code in nbtsplitloc.c.  

commit   : 9950c8aadf0edd31baec74a729d47d94af636c06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 18:31:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 18:31:05 -0400    

Something like "*{2}.*{3}" should presumably mean the same as  
"*{5}", but it didn't.  Improve that.  
  
Get rid of an undocumented and remarkably ugly (though not, as far as  
I can tell, actually unsafe) static variable in favor of passing more  
arguments to checkCond().  
  
Reverse-engineer some commentary.  This function, like all of ltree,  
is still far short of what I would consider the minimum acceptable  
level of internal documentation, but at least now it has more than  
zero comments.  
  
Although this certainly seems like a bug fix, people might not  
thank us for changing query behavior in stable branches, so  
no back-patch.  
  
Nikita Glukhov, with cosmetic improvements by me  
  
Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com  

commit   : 95f7ddfdad99c5ea0500d90ce52075814e10ed8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 17:09:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 17:09:51 -0400    

These uint16 fields could be overflowed by excessively long input,  
producing strange results.  Complain for invalid input.  
  
Likewise check for out-of-range values of the repeat counts in lquery.  
(We don't try too hard on that one, notably not bothering to detect  
if atoi's result has overflowed.)  
  
Also detect length overflow in ltree_concat.  
  
In passing, be more consistent about whether "syntax error" messages  
include the type name.  Also, clarify the documentation about what  
the size limit is.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Nikita Glukhov, reviewed by Benjie Gillam and Tomas Vondra  
  
Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com  

commit   : 42750b08d946e2a5048454d7b4e127f0e1df3c65    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 28 Mar 2020 11:52:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 28 Mar 2020 11:52:11 -0700    

In 9.4 I added support to use a historical snapshot in  
ScanPgRelation(), while adding logical decoding. Unfortunately a  
conflict with the concurrent removal of SnapshotNow was incorrectly  
resolved, leading to an unregistered snapshot being used.  
  
It is not correct to use an unregistered (or non-active) snapshot for  
anything non-trivial, because catalog invalidations can cause the  
snapshot to be invalidated.  
  
Luckily it seems unlikely to actively cause problems in practice, as  
ScanPgRelation() requires that we already have a lock on the relation,  
we only look for a single row, and we don't appear to rely on the  
result's tid to be correct. It however is clearly wrong and potential  
negative consequences would likely be hard to find. So it seems worth  
backpatching the fix, even without a concrete hazard.  
  
Discussion: https://postgr.es/m/20200229052459.wzhqnbhrriezg4v2@alap3.anarazel.de  
Backpatch: 9.5-  

commit   : 7351bfeda33b60b69c15791c7eb77a127546df26    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 28 Mar 2020 10:53:01 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 28 Mar 2020 10:53:01 -0700    

Report and suggestions from Richard Guo and Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAMbWs4_W8fYbAn8KxgidAaZHON_Oo08OYn9ze=7remJymLqo5g@mail.gmail.com  

commit   : 4083f445c0cbda2eacb6b17297f9d555397e5eaa    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 14:37:53 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 14:37:53 +0000    

Instead of using Newton's method to compute numeric square roots, use  
the Karatsuba square root algorithm, which performs better for numbers  
of all sizes. In practice, this is 3-5 times faster for inputs with  
just a few digits and up to around 10 times faster for larger inputs.  
  
Also, the new algorithm guarantees that the final digit of the result  
is correctly rounded, since it computes an integer square root with  
truncation, containing at least 1 extra decimal digit before rounding.  
The former algorithm would occasionally round the wrong way because  
it rounded both the intermediate and final results.  
  
In addition, arrange for sqrt_var() to explicitly support negative  
rscale values (rounding before the decimal point). This allows the  
argument reduction phase of ln_var() to be optimised for large inputs,  
since it only needs to compute square roots with a few more digits  
than the final ln() result, rather than computing all the digits  
before the decimal point. For very large inputs, this can be many  
thousands of times faster.  
  
In passing, optimise div_var_fast() in a couple of places where it was  
doing unnecessary work.  
  
Patch be me, reviewed by Tom Lane and Tels.  
  
Discussion: https://postgr.es/m/CAEZATCV1A7+jD3P30Zu31KjaxeSEyOn3v9d6tYegpxcq3cQu-g@mail.gmail.com  

commit   : 8f3ec75de4060d86176ad4ac998eeb87a39748c2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 13:01:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 13:01:42 +0100    

As of Windows 10 version 1803, Unix-domain sockets are supported on  
Windows.  But it's not automatically detected by configure because it  
looks for struct sockaddr_un and Windows doesn't define that.  So we  
just make our own definition on Windows and override the configure  
result.  
  
Set DEFAULT_PGSOCKET_DIR to empty on Windows so by default no  
Unix-domain socket is used, because there is no good standard  
location.  
  
In pg_upgrade, we have to do some extra tweaking to preserve the  
existing behavior of not using Unix-domain sockets on Windows.  Adding  
support would be desirable, but it needs further work, in particular a  
way to select whether to use Unix-domain sockets from the command-line  
or with a run-time test.  
  
The pg_upgrade test script needs a fix.  The previous code passed  
"localhost" to postgres -k, which only happened to work because  
Windows used to ignore the -k argument value altogether.  We instead  
need to pass an empty string to get the desired effect.  
  
The test suites will continue to not use Unix-domain sockets on  
Windows.  This requires a small tweak in pg_regress.c.  The TAP tests  
don't need to be changed because they decide by the operating system  
rather than HAVE_UNIX_SOCKETS.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : 87779aa47463d0fb3b4743a7d5c9534994bf7c98    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 12:48:34 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 12:48:34 +0000    

Formerly we applied a functional dependency "a => b with dependency  
degree f" using the formula  
  
  P(a,b) = P(a) * [f + (1-f)*P(b)]  
  
This leads to the possibility that the combined selectivity P(a,b)  
could exceed P(b), which is not ideal. The addition of support for IN  
and OR clauses (commits 8f321bd16c and ccaa3569f5) would seem to make  
this more likely, since the user-supplied values in such clauses are  
not necessarily compatible with the functional dependency.  
  
Mitigate this by using the formula  
  
  P(a,b) = f * Min(P(a), P(b)) + (1-f) * P(a) * P(b)  
  
instead, which guarantees that the combined selectivity is less than  
each column's individual selectivity. Logically, this is modifies the  
part of the formula that accounts for dependent rows to handle cases  
where P(a) > P(b), whilst not changing the second term which accounts  
for independent rows.  
  
Additionally, this refactors the way that functional dependencies are  
applied, so now dependencies_clauselist_selectivity() estimates both  
the implying clauses and the implied clauses for each functional  
dependency (formerly only the implied clauses were estimated), and now  
all clauses for each attribute are taken into account (formerly only  
one clause for each implied attribute was estimated). This removes the  
previously built-in assumption that only equality clauses will be  
seen, which is no longer true, and opens up the possibility of  
applying functional dependencies to more general clauses.  
  
Patch by me, reviewed by Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAEZATCXaNFZyOhR4XXAfkvj1tibRBEjje6ZbXwqWUB_tqbH%3Drw%40mail.gmail.com  
Discussion: https://postgr.es/m/20200318002946.6dvblukm3cfmgir2%40development  

commit   : 145cb16d3bd7d20dbf14507905404aa8153ebf2a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 08:46:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 08:46:18 +0100    

Feature C011 was still listed in sql_feature_packages.txt but had been  
removed from sql_features.txt, so also remove from the former.  

commit   : b07642dbcd8d5de05f0ee1dbb72dd6760dd30436    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 28 Mar 2020 19:20:12 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 28 Mar 2020 19:20:12 +1300    

Traditionally autovacuum has only ever invoked a worker based on the  
estimated number of dead tuples in a table and for anti-wraparound  
purposes. For the latter, with certain classes of tables such as  
insert-only tables, anti-wraparound vacuums could be the first vacuum that  
the table ever receives. This could often lead to autovacuum workers being  
busy for extended periods of time due to having to potentially freeze  
every page in the table. This could be particularly bad for very large  
tables. New clusters, or recently pg_restored clusters could suffer even  
more as many large tables may have the same relfrozenxid, which could  
result in large numbers of tables requiring an anti-wraparound vacuum all  
at once.  
  
Here we aim to reduce the work required by anti-wraparound and aggressive  
vacuums in general, by triggering autovacuum when the table has received  
enough INSERTs. This is controlled by adding two new GUCs and reloptions;  
autovacuum_vacuum_insert_threshold and  
autovacuum_vacuum_insert_scale_factor. These work exactly the same as the  
existing scale factor and threshold controls, only base themselves off the  
number of inserts since the last vacuum, rather than the number of dead  
tuples. New controls were added rather than reusing the existing  
controls, to allow these new vacuums to be tuned independently and perhaps  
even completely disabled altogether, which can be done by setting  
autovacuum_vacuum_insert_threshold to -1.  
  
We make no attempt to skip index cleanup operations on these vacuums as  
they may trigger for an insert-mostly table which continually doesn't have  
enough dead tuples to trigger an autovacuum for the purpose of removing  
those dead tuples. If we were to skip cleaning the indexes in this case,  
then it is possible for the index(es) to become bloated over time.  
  
There are additional benefits to triggering autovacuums based on inserts,  
as tables which never contain enough dead tuples to trigger an autovacuum  
are now more likely to receive a vacuum, which can mark more of the table  
as "allvisible" and encourage the query planner to make use of Index Only  
Scans.  
  
Currently, we still obey vacuum_freeze_min_age when triggering these new  
autovacuums based on INSERTs. For large insert-only tables, it may be  
beneficial to lower the table's autovacuum_freeze_min_age so that tuples  
are eligible to be frozen sooner. Here we've opted not to zero that for  
these types of vacuums, since the table may just be insert-mostly and we  
may otherwise freeze tuples that are still destined to be updated or  
removed in the near future.  
  
There was some debate to what exactly the new scale factor and threshold  
should default to. For now, these are set to 0.2 and 1000, respectively.  
There may be some motivation to adjust these before the release.  
  
Author: Laurenz Albe, Darafei Praliaskouski  
Reviewed-by: Alvaro Herrera, Masahiko Sawada, Chris Travers, Andres Freund, Justin Pryzby  
Discussion: https://postgr.es/m/CAC8Q8t%2Bj36G_bLF%3D%2B0iMo6jGNWnLnWb1tujXuJr-%2Bx8ZCCTqoQ%40mail.gmail.com  

commit   : 9945ad6e904041be1567a89916ddc64087ed1edc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Mar 2020 16:44:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Mar 2020 16:44:52 -0700    

Delaying unlocking the right child page until after the point that the  
left child's parent page has been refound is no longer truly necessary.  
Commit 40dae7ec made nbtree tolerant of interrupted page splits.  VACUUM  
was taught to avoid deleting a page that happens to be the right half of  
an incomplete split.  As long as page splits don't unlock the left child  
page until the end of the second/final phase, it should be safe to  
unlock the right child page earlier (at the end of the first phase).  
  
It probably isn't actually useful to release the right child's lock  
earlier like this (it probably won't improve performance).  Even still,  
pointing out that it ought to be safe to do so should make it easier to  
understand the overall design.  

commit   : 1e6148032e4d27aec75c49264b47ad193405a919    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 19:43:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 19:43:41 -0300    

The parameters primary_conninfo, primary_slot_name and  
wal_receiver_create_temp_slot can now be changed with a simple "reload"  
signal, no longer requiring a server restart.  This is achieved by  
signalling the walreceiver process to terminate and having it start  
again with the new values.  
  
Thanks to Andres Freund, Kyotaro Horiguchi, Fujii Masao for discussion.  
  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/19513901543181143@sas1-19a94364928d.qloud-c.yandex.net  

commit   : 092c6936de49effe63daad94855bcd8ef26a09dd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 16:04:52 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 16:04:52 -0300    

Commit 329730827848 gave walreceiver the ability to create and use a  
temporary replication slot, and made it controllable by a GUC (enabled  
by default) that can be changed with SIGHUP.  That's useful but has two  
problems: one, it's possible to cause the origin server to fill its disk  
if the slot doesn't advance in time; and also there's a disconnect  
between state passed down via the startup process and GUCs that  
walreceiver reads directly.  
  
We handle the first problem by setting the option to disabled by  
default.  If the user enables it, its on their head to make sure that  
disk doesn't fill up.  
  
We handle the second problem by passing the flag via startup rather than  
having walreceiver acquire it directly, and making it PGC_POSTMASTER  
(which ensures a walreceiver always has the fresh value).  A future  
commit can relax this (to PGC_SIGHUP again) by having the startup  
process signal walreceiver to shutdown whenever the value changes.  
  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200122055510.GH174860@paquier.xyz  

commit   : fbc7a716084ebccd2a996cc415187c269ea54b3e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Mar 2020 14:47:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Mar 2020 14:47:34 -0400    

Buildfarm experience shows what probably should've occurred to me before:  
if a cache flush occurs partway through building a generic plan, then  
the plansource may have is_valid = false even though the plan is valid.  
We need to accept this case, use the generated plan, and then try to  
replan the next time.  We can't try to replan immediately, because that  
would produce an infinite loop in CLOBBER_CACHE_ALWAYS builds; moreover  
it's really overkill.  (We can assume that the plan is valid, it's just  
possibly a bit stale.  Note that the pre-existing code behaved this way,  
and the non-simple-expression code paths do too.)  Conversely, not using  
the generated plan would drop us into the not-a-simple-expression code  
path, which is bad for performance and would also cause regression-test  
failures due to visibly different error-reporting behavior.  
  
Hence, refactor the validity-check functions so that the initial check  
and recheck cases can react differently to plansource->is_valid.  
This makes their usage a bit simpler, too.  
  
Discussion: https://postgr.es/m/7072.1585332104@sss.pgh.pa.us  

commit   : 8d1b9648c5861dd14773e551f0b0f37f7ff22820    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Mar 2020 08:36:08 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Mar 2020 08:36:08 +0100    

Change F311 to supported.  This was already accomplished when  
subfeature F311-04 (WITH CHECK OPTION) was added, but the top-level  
feature wasn't updated at the time.  

commit   : 8f59f6b9c0376173a072e4fb7de1edd6a26e6b52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:58:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:58:57 -0400    

For relatively simple expressions (say, "x + 1" or "x > 0"), plpgsql's  
management overhead exceeds the cost of evaluating the expression.  
This patch substantially improves that situation, providing roughly  
2X speedup for such trivial expressions.  
  
First, add infrastructure in the plancache to allow fast re-validation  
of cached plans that contain no table access, and hence need no locks.  
Teach plpgsql to use this infrastructure for expressions that it's  
already deemed "simple" (which in particular will never contain table  
references).  
  
The fast path still requires checking that search_path hasn't changed,  
so provide a fast path for OverrideSearchPathMatchesCurrent by  
counting changes that have occurred to the active search path in the  
current session.  This is simplistic but seems enough for now, seeing  
that PushOverrideSearchPath is not used in any performance-critical  
cases.  
  
Second, manage the refcounts on simple expressions' cached plans using  
a transaction-lifespan resource owner, so that we only need to take  
and release an expression's refcount once per transaction not once per  
expression evaluation.  The management of this resource owner exactly  
parallels the existing management of plpgsql's simple-expression EState.  
  
Add some regression tests covering this area, in particular verifying  
that expression caching doesn't break semantics for search_path changes.  
  
Patch by me, but it owes something to previous work by Amit Langote,  
who recognized that getting rid of plancache-related overhead would  
be a useful thing to do here.  Also thanks to Andres Freund for review.  
  
Discussion: https://postgr.es/m/CAFj8pRDRVfLdAxsWeVLzCAbkLFZhW549K+67tpOc-faC8uH8zw@mail.gmail.com  

commit   : 86e5badd22d9ae131a2badb87acdbb20e41811a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:06:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:06:55 -0400    

plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and  
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT  
respectively, since its goal is to do process-local cleanup.  This  
oversight caused plpgsql's end-of-transaction cleanup to not get done  
in parallel workers.  Since a parallel worker will exit just after the  
transaction cleanup, the effects of this are limited.  I couldn't find  
any case in the core code with user-visible effects, but perhaps there  
are some in extensions.  In any case it's wrong, so let's fix it before  
it bites us not after.  
  
In passing, add some comments around the handling of expression  
evaluation resources in DO blocks.  There's no live bug there, but it's  
quite unobvious what's happening; at least I thought so.  This isn't  
related to the other issue, except that I found both things while poking  
at expression-evaluation performance.  
  
Back-patch the plpgsql_xact_cb fix to 9.5 where those event types  
were introduced, and the DO-block commentary to v11 where DO blocks  
gained the ability to issue COMMIT/ROLLBACK.  
  
Discussion: https://postgr.es/m/10353.1585247879@sss.pgh.pa.us  

commit   : eff5b245df259c73d8342e2f04dba5a832d2ea0a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 Mar 2020 15:05:54 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 Mar 2020 15:05:54 +0100    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 49bf81536e242f079bfbce6e8f95f53f18207dd5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 11:51:39 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 11:51:39 +0100    

When SaveSlotToPath() is called with elevel=LOG, the early exits didn't  
release the slot's io_in_progress_lock.  
  
This could result in a walsender being stuck on the lock forever.  A  
possible way to get into this situation is if the offending code paths  
are triggered in a low disk space situation.  
  
Author: Pavan Deolasee <pavan.deolasee@2ndquadrant.com>  
Reported-by: Craig Ringer <craig@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/56a138c5-de61-f553-7e8f-6789296de785%402ndquadrant.com  

commit   : 958aa438aaa473d580f60154786ffd716a28faf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 22:05:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 22:05:19 -0400    

The Makefile should set TAP_TESTS = 1, not implement the infrastructure  
for itself.  For one thing, it missed the appropriate "make clean"  
steps.  For another, the buildfarm isn't running this test because  
it wasn't hooked into "make installcheck" either.  

commit   : e984fb341f293ab21c7d63897357ffca08280268    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 21:14:14 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 21:14:14 -0400    

Commit 896fcdb230 contained an unnecessary setting that listened to  
localhost. Since the test doesn't actually try to make an SSL connection  
to the database this isn't required. Moreover, it's a security hole.  
  
Per gripe from Tom Lane.  

commit   : 13c98bdfc41eefb75da24fd2a886b0ef5314b7f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 19:37:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 19:37:30 -0400    

Some platforms require libssl to be linked explicitly in the new  
SSL test module.  Borrow contrib/sslinfo's code for that.  
  
Since src/test/modules/Makefile now has a variable SUBDIRS list,  
it needs to follow the ALWAYS_SUBDIRS protocol for that (cf.  
comments in Makefile.global.in).  
  
Blindly try to fix MSVC build failures by adding PGDLLIMPORT.  

commit   : 896fcdb230e729652d37270c8606ccdc45212f0d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 17:13:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 17:13:17 -0400    

The default hook function sets the default password callback function.  
In order to allow preloaded libraries to have an opportunity to override  
the default, TLS initialization if now delayed slightly until after  
shared preloaded libraries have been loaded.  
  
A test module is provided which contains a trivial example that decodes  
an obfuscated password for an SSL certificate.  
  
Author: Andrew Dunstan  
Reviewed By: Andreas Karlsson, Asaba Takanori  
Discussion: https://postgr.es/m/04116472-818b-5859-1d74-3d995aab2252@2ndQuadrant.com  

commit   : ffd398021c296e55b59ab848ac71a1769ddff93f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 15:14:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 15:14:14 -0300    

Some getopt_long implementations don't like to have a non-option  
argument before option arguments, so put the database name as the  
last switch.  
  
Per buildfarm member hoverfly.  

commit   : 2f9eb31320948b968e5f744b73032405e1f25225    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 13:19:31 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 13:19:31 -0300    

The new command-line switch --include-foreign-data=PATTERN lets the user  
specify foreign servers from which to dump foreign table data.  This can  
be refined by further inclusion/exclusion switches, so that the user has  
full control over which tables to dump.  
  
A limitation is that this doesn't work in combination with parallel  
dumps, for implementation reasons.  This might be lifted in the future,  
but requires shuffling some code around.  
  
Author: Luis Carril <luis.carril@swarm64.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Surafel Temesgen <surafel3000@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@2ndQuadrant.com>  
Discussion: https://postgr.es/m/LEJPR01MB0185483C0079D2F651B16231E7FC0@LEJPR01MB0185.DEUPRD01.PROD.OUTLOOK.DE  

commit   : bda6dedbea599209048bc51115ecb2062ceb976c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 11:57:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 11:57:36 -0400    

This reverts the parts of commit 17a28b03645e27d73bf69a95d7569b61e58f06eb  
that changed ereport's auxiliary functions from returning dummy integer  
values to returning void.  It turns out that a minority of compilers  
complain (not entirely unreasonably) about constructs such as  
  
	(condition) ? errdetail(...) : 0  
  
if errdetail() returns void rather than int.  We could update those  
call sites to say "(void) 0" perhaps, but the expectation for this  
patch set was that ereport callers would not have to change anything.  
And this aspect of the patch set was already the most invasive and  
least compelling part of it, so let's just drop it.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : f5817595a7f194d25bc9be5b035eb1f7f60cd1fa    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 14:23:25 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 14:23:25 +0100    

It was for unclear reasons defined in a separate location, which makes  
it more cumbersome to override for testing, and it also did not have  
any prominent documentation.  Move to pg_config_manual.h, where  
similar things are already collected.  
  
The previous definition on the command-line had the effect of defining  
it to the value 1, but now that we don't need that anymore we just  
define it to empty, to simplify manual editing a bit.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/b7053ba8-b008-5335-31de-2fe4fe41ef0f%402ndquadrant.com  

commit   : e8b1774fc288d7f789a539ef0a768aff2deef600    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 08:46:41 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 08:46:41 +0100    

The name of E182 was changed in SQL:2011.  
  
Also, we can change it to supported because all it requires is one  
embedded language to be supported, which we do.  

commit   : 352f6f2df60f8725cf6e81141985977d76c169d3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:56:00 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:56:00 +1300    

On Vista and later, use GetNLSVersionEx() to request collation version  
information.  
  
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJvqup3s%2BJowVTcacZADO6dOhfdBmvOPHLS3KXUJu41Jw%40mail.gmail.com  

commit   : 382a821907e76bf6068492a164fdfc57578391f4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:53:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:53:24 +1300    

Remove the documented restriction that collation providers must either  
return NULL for all collations or non-NULL for all collations.  
  
Use NULL for glibc collations like "C.UTF-8", which might otherwise lead  
future proposed commits to force unnecessary index rebuilds.  
  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJvqup3s%2BJowVTcacZADO6dOhfdBmvOPHLS3KXUJu41Jw%40mail.gmail.com  

commit   : dd8e19132acfbb28d579288a412ed6c0a5ea338b    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:51 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:51 -0700    

Correct oversight in 1f39bce0. If enable_hashagg_disk=true, we should  
consider hash aggregation for DISTINCT when applicable.  

commit   : 3649133b147638f25933c93e3d4f6b920da50332    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:34 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:34 -0700    

If there are no aggregates, there is no need to allocate an array of  
zero AggStatePerGroupData elements.  

commit   : b150a76793109b00ea43c26e0006b3cad9030096    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Mar 2020 14:58:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Mar 2020 14:58:27 -0700    

Descriptions of some aspects of how deduplication works were unclear in  
a couple of places.  

commit   : 112b006fe79b6fe84647df84a07c201e5a7b1635    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Mar 2020 12:14:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Mar 2020 12:14:18 -0700    

Measurements show, and intuition agrees, that there's currently no  
known cases where adding a fastpath to avoid allocating / ordering a  
heap for a single transaction is worthwhile.  
  
Author: Dilip Kumar  
Discussion: https://postgr.es/m/CAFiTN-sp701wvzvnLQJGk7JDqrFM8f--97-ihbwkU8qvn=p8nw@mail.gmail.com  

commit   : f15ace793578d96d70dad1e613293ae3eab92503    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 19:29:34 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 19:29:34 +0100    

bf68b79e50e3359accc85c94fa23cc03abb9350a introduced an unused variable  
compiler warning on Cygwin.  

commit   : 17a28b03645e27d73bf69a95d7569b61e58f06eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 12:08:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 12:08:48 -0400    

Change all the auxiliary error-reporting routines to return void,  
now that we no longer need to pretend they are passing something  
useful to errfinish().  While this probably doesn't save anything  
significant at the machine-code level, it allows detection of some  
additional types of mistakes.  
  
Pass the error location details (__FILE__, __LINE__, PG_FUNCNAME_MACRO)  
to errfinish not errstart.  This shaves a few cycles off the case where  
errstart decides we're not going to emit anything.  
  
Re-implement elog() as a trivial wrapper around ereport(), removing  
the separate support infrastructure it used to have.  Aside from  
getting rid of some now-surplus code, this means that elog() now  
really does have exactly the same semantics as ereport(), in particular  
that it can skip evaluation work if the message is not to be emitted.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : e3a87b4991cc2d00b7a3082abb54c5f12baedfd1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 11:48:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 11:48:33 -0400    

Now that we require C99, we can depend on __VA_ARGS__ to work, and  
revising ereport() to use it has several significant benefits:  
  
* The extra parentheses around the auxiliary function calls are now  
optional.  Aside from being a bit less ugly, this removes a common  
gotcha for new contributors, because in some cases the compiler errors  
you got from forgetting them were unintelligible.  
  
* The auxiliary function calls are now evaluated as a comma expression  
list rather than as extra arguments to errfinish().  This means that  
compilers can be expected to warn about no-op expressions in the list,  
allowing detection of several other common mistakes such as forgetting  
to add errmsg(...) when converting an elog() call to ereport().  
  
* Unlike the situation with extra function arguments, comma expressions  
are guaranteed to be evaluated left-to-right, so this removes platform  
dependency in the order of the auxiliary function calls.  While that  
dependency hasn't caused us big problems in the past, this change does  
allow dropping some rather shaky assumptions around errcontext() domain  
handling.  
  
There's no intention to make wholesale changes of existing ereport  
calls, but as proof-of-concept this patch removes the extra parens  
from a couple of calls in postgres.c.  
  
While new code can be written either way, code intended to be  
back-patched will need to use extra parens for awhile yet.  It seems  
worth back-patching this change into v12, so as to reduce the window  
where we have to be careful about that by one year.  Hence, this patch  
is careful to preserve ABI compatibility; a followup HEAD-only patch  
will make some additional simplifications.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : cef27ae01ac872355b2bd56c0882aafe5c6f08de    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 16:01:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 16:01:06 +0100    

A variable was unused in non-assert builds.  Simplify the code to  
avoid the issue.  
  
Reported-by: Erik Rijkers <er@xs4all.nl>  

commit   : ab3e4fbd5421e9b3203de9ebf6a741eebab2ab94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 10:27:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 10:27:02 -0400    

Sloppiness in commit cedffbdb8, noted by Erikjan Rijkers.  
(It's fairly unfortunate that xmllint doesn't catch this.)  
  
Discussion: https://postgr.es/m/2e3dc9e4bfa4802d2c9f5fe15bde44de@xs4all.nl  

commit   : 97ee604d9bcedf0066986521a7ee15e3aa87be34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 14:00:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 14:00:58 +0100    

This moves the main operations of apply_handle_{insert|update|delete},  
that of inserting, updating, deleting a tuple into/from a given  
relation, into corresponding  
apply_handle_{insert|update|delete}_internal functions.  This allows  
performing those operations on relations that are not directly the  
targets of replication, which is something a later patch will use for  
targeting partitioned tables.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : d40d564c5a920e1121b28463dfed74441cbae5c0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 08:49:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 08:49:52 +0100    

It previously only supported NFKC, for use by SASLprep.  This expands  
the API to offer the choice of all four normalization forms.  Right  
now, there are no internal users of the forms other than NFKC.  
  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Discussion: https://www.postgresql.org/message-id/flat/c1909f27-c269-2ed9-12f8-3ab72c8caf7a@2ndquadrant.com  

commit   : cedffbdb8b137325a79e07a976457bc2314adf9b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 22:19:56 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 22:19:56 -0700    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200321040750.GD13662@telsasoft.com  

commit   : 496ee647ecd2917369ffcf1eaa0b2cdca07c8730    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 12:46:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 12:46:48 +0900    

Previously if a promotion was triggered while recovery was paused,  
the paused state continued. Also recovery could be paused by executing  
pg_wal_replay_pause() even while a promotion was ongoing. That is,  
recovery pause had higher priority over a standby promotion.  
But this behavior was not desirable because most users basically wanted  
the recovery to complete as soon as possible and the server to become  
the master when they requested a promotion.  
  
This commit changes recovery so that it prefers a promotion over  
recovery pause. That is, if a promotion is triggered while recovery  
is paused, the paused state ends and a promotion continues. Also  
this commit makes recovery pause functions like pg_wal_replay_pause()  
throw an error if they are executed while a promotion is ongoing.  
  
Internally, this commit adds new internal function PromoteIsTriggered()  
that returns true if a promotion is triggered. Since the name of  
this function and the existing function IsPromoteTriggered() are  
confusingly similar, the commit changes the name of IsPromoteTriggered()  
to IsPromoteSignaled, as more appropriate name.  
  
Author: Fujii Masao  
Reviewed-by: Atsushi Torikoshi, Sergei Kornilov  
Discussion: https://postgr.es/m/00c194b2-dbbb-2e8a-5b39-13f14048ef0a@oss.nttdata.com  

commit   : e09ad07b21a244c3cbcdbe3048e9ab0834ac6d41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Mar 2020 12:13:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Mar 2020 12:13:36 +0900    

restore_command has only been used until now by the backend, but there  
is a pending patch for pg_rewind to make use of that in the frontend.  
  
Author: Alexey Kondratov  
Reviewed-by: Andrey Borodin, Andres Freund, Alvaro Herrera, Alexander  
Korotkov, Michael Paquier  
Discussion: https://postgr.es/m/a3acff50-5a0d-9a2c-b3b2-ee36168955c1@postgrespro.ru  

commit   : b8e20d6dabdafbe905b62910dc0236037c7881e1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 11:12:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 11:12:21 +0900    

This commit introduces new wait events BackupWaitWalArchive and  
RecoveryPause. The former is reported while waiting for the WAL files  
required for the backup to be successfully archived. The latter is  
reported while waiting for recovery in pause state to be resumed.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Atsushi Torikoshi, Robert Haas  
Discussion: https://postgr.es/m/f0651f8c-9c96-9f29-0ff9-80414a15308a@oss.nttdata.com  

commit   : 76df765e88fd9016e4b4f75dc69bcd9a1f335f72    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 18:55:12 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 18:55:12 -0700    

Discussion: https://postgr.es/m/23196.1584943506@sss.pgh.pa.us  

commit   : 67e0adfb3f98f1e4a89a32b6f2e59774ce579146    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 10:43:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 10:43:41 +0900    

Previously 0 was reported in pg_stat_progress_basebackup.total_backup  
if the total backup size was not estimated. Per discussion, our consensus  
is that NULL is better choise as the value in total_backup in that case.  
So this commit makes pg_stat_progress_basebackup view report NULL  
in total_backup column if the estimation is disabled.  
  
Bump catversion.  
  
Author: Fujii Masao  
Reviewed-by: Amit Langote, Magnus Hagander, Alvaro Herrera  
Discussion: https://postgr.es/m/CABUevExnhOD89zBDuPvfAAh243RzNpwCPEWNLtMYpKHMB8gbAQ@mail.gmail.com  

commit   : 64fe6022790920ef6edee475bfa162a961f148d8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 13:56:28 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 13:56:28 -0700    

Justin Pryzby raised a couple issues with commit 1f39bce0. Fixed.  
  
Also, tweak the way the size of a hash entry is estimated and the  
number of buckets is estimated when calling BuildTupleHashTableExt().  
  
Discussion: https://www.postgresql.org/message-id/20200319064222.GR26184@telsasoft.com  

commit   : 0830d21f5b01064837dc8bd910ab31a5b7a1101a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 23 Mar 2020 18:38:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 23 Mar 2020 18:38:42 -0400    

backend_type was added to the CVS log output in commit 70a7b4776b.  
  
Reported-by: Fabrízio de Royes Mello  
  
Discussion: https://postgr.es/m/CAFcNs+ruvRks3BV1j7yQ-MvxsswmKJa0cVh2yK5Dd-xXVM8wPw@mail.gmail.com  
  
Backpatch-through: master  

commit   : f801ceb696b4a865ef80fd29c9df880280472e03    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 14:48:19 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 14:48:19 -0700    

While #16293 only applied to 11 (and 10 to some degree), it seems best  
to add tests to all branches with partitioning support.  
  
Reported-By: Daniel WM  
Author: Andres Freund  
Bug: #16293  
Discussion: https://postgr.es/m/16293-26f5777d10143a66@postgresql.org  
Backpatch: 10-  

commit   : 0df94beb362e0ebc812170fbabd1aaf75136831a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 24 Mar 2020 00:54:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 24 Mar 2020 00:54:33 +0300    

commit   : fe604800681aed8228fbe67d2e175d6822c66ea2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 12:42:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 12:42:15 -0400    

This wasn't stated anywhere, and it's perhaps not that obvious,  
since we get questions about it from time to time.  Also undocumented  
was that the parser actually translates these into operators.  
  
Discussion: https://postgr.es/m/CAFj8pRBkvZ71BqGKZnBBG4=0cKG+s50Dy+DYmrizUKEpAtdc+w@mail.gmail.com  

commit   : 980a70b9763e330dab6d0eb994c96a007876e40e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 11:58:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 11:58:00 -0400    

src/port/getopt_long.c failed on such an argument, always seeing it  
as an unrecognized switch.  This is unhelpful; better is to treat such  
an item as a non-switch argument.  That behavior is what we find in  
GNU's getopt_long(); it's what src/port/getopt.c does; and it is  
required by POSIX for getopt(), which getopt_long() ought to be  
generally a superset of.  Moreover, it's expected by ecpg, which  
intends an argument of "-" to mean "read from stdin".  So fix it.  
  
Also add some documentation about ecpg's behavior in this area, since  
that was miserably underdocumented.  I had to reverse-engineer it  
from the code.  
  
Per bug #16304 from James Gray.  Back-patch to all supported branches,  
since this has been broken forever.  
  
Discussion: https://postgr.es/m/16304-c662b00a1322db7f@postgresql.org  

commit   : c81bd3b9a5e99315148f4f5714c32e633af30123    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 13:38:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 13:38:03 +0900    

autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor have  
been documented as "float4", but "floating type" is used in this case  
for GUCs and relation options in the documentation.  
  
Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFf_p9BpbjLccx3CA=eM1Hk2Te=ULY4iptGLUhL-JxCPA@mail.gmail.com  
Backpatch-through: 9.5  

commit   : faa650a99b4bfbe95e88f44070ae0df1818944a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 12:52:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 12:52:37 +0900    

This reverts commit b7f64c6, which broke the fallback implementation for  
C++.  We have discussed a couple of alternatives to reduce the number of  
implementations for those asserts, but nothing allowing to reduce the  
number of implementations down to three instead of four, so there is no  
benefit in keeping this patch.  
  
Thanks to Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/20200313115033.GA183471@paquier.xyz  

commit   : 33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 23 Mar 2020 08:09:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 23 Mar 2020 08:09:15 +0530    

All errors of SQLSTATE class 23 should include the name of an object  
associated with the error in separate fields of the error report message.  
We do this so that applications need not try to extract them from the  
possibly-localized human-readable text of the message.  
  
Reported-by: Chris Bandy  
Author: Chris Bandy  
Reviewed-by: Amit Kapila and Amit Langote  
Discussion: https://postgr.es/m/0aa113a3-3c7f-db48-bcd8-f9290b2269ae@gmail.com  

commit   : 79dfa8afb296e1b0dcffbe674e04c5f25cc13dfd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 11:01:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 11:01:41 +0900    

Mixing incorrect bounds in the SSL context leads to confusing error  
messages generated by OpenSSL which are hard to act on.  New range  
checks are added when both min/max parameters are loaded in the context  
of a SSL reload to improve the error reporting.  Note that this does not  
make use of the GUC hook machinery contrary to 41aadee, as there is no  
way to ensure a consistent range check (except if there is a way one day  
to define range types for GUC parameters?).  Hence, this patch applies  
only to OpenSSL, and uses a logic similar to other parameters to trigger  
an error when reloading the SSL context in a session.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200114035420.GE1515@paquier.xyz  

commit   : de9396326edcbe5cafc06a72016f9d715c350e0e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 22 Mar 2020 09:24:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 22 Mar 2020 09:24:09 -0700    

This reverts commit cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f.  Per  
numerous buildfarm members, it was incompatible with parallel query, and  
a test case assumed LP64.  Back-patch to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20200321224920.GB1763544@rfd.leadboat.com  

commit   : d0587f52b3bb898db3c0011954de6ae9adc076c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Mar 2020 18:28:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Mar 2020 18:28:44 -0400    

headerscheck and cpluspluscheck should skip the recently-added  
cmdtaglist.h header, since (like kwlist.h and some other similarly-  
designed headers) it's not meant to be included standalone.  
  
evtcache.h was missing an #include to support its usage of Bitmapset.  
  
typecmds.h was missing an #include to support its usage of ParseState.  
  
The first two of these were evidently oversights in commit 2f9661311.  
I didn't track down exactly which change broke typecmds.h, but it  
must have been some rearrangement in one of its existing inclusions,  
because it's referenced ParseState for quite a long time and there  
were not complaints from these checking programs before.  

commit   : cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

Until now, only selected bulk operations (e.g. COPY) did this.  If a  
given relfilenode received both a WAL-skipping COPY and a WAL-logged  
operation (e.g. INSERT), recovery could lose tuples from the COPY.  See  
src/backend/access/transam/README section "Skipping WAL for New  
RelFileNode" for the new coding rules.  Maintainers of table access  
methods should examine that section.  
  
To maintain data durability, just before commit, we choose between an  
fsync of the relfilenode and copying its contents to WAL.  A new GUC,  
wal_skip_threshold, guides that choice.  If this change slows a workload  
that creates small, permanent relfilenodes under wal_level=minimal, try  
adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may  
need to adjust that timeout, and log_min_duration_statement analysis  
will reflect time consumption moving to COMMIT from commands like COPY.  
  
Internally, this requires a reliable determination of whether  
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's  
current relfilenode.  Introduce rd_firstRelfilenodeSubid.  Amend the  
specification of rd_createSubid such that the field is zero when a new  
rel has an old rd_node.  Make relcache.c retain entries for certain  
dropped relations until end of transaction.  
  
Back-patch to 9.5 (all supported versions).  This introduces a new WAL  
record type, XLOG_GIST_ASSIGN_LSN, without bumping XLOG_PAGE_MAGIC.  As  
always, update standby systems before master systems.  This changes  
sizeof(RelationData) and sizeof(IndexStmt), breaking binary  
compatibility for affected extensions.  (The most recent commit to  
affect the same class of extensions was  
089e4d405d0f3b94c74a2c6a54357a84a681754b.)  
  
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert  
Haas.  Heikki Linnakangas and Michael Paquier implemented earlier  
designs that materially clarified the problem.  Reviewed, in earlier  
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,  
Fujii Masao, and Simon Riggs.  Reported by Martijn van Oosterhout.  
  
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org  

commit   : d3e572855be1e15c7e0a6adc8db52b9fd4f71be0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

The function assumed forkNum=MAIN_FORKNUM and page_std=true, ignoring  
the actual arguments.  Existing callers passed exactly those values, so  
there's no live bug.  Back-patch to v12, where the function first  
appeared, because another fix needs this.  
  
Discussion: https://postgr.es/m/20191118045434.GA1173436@rfd.leadboat.com  

commit   : e629a01f6973688f77ecff964d9d6bea9bc4b374    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

swap_relation_files() calls toast_get_valid_index() to find and lock  
this index, just before swapping with the rebuilt TOAST index.  The  
latter function releases the lock before returning.  Potential for  
mischief is low; a concurrent session can issue ALTER INDEX ... SET  
(fillfactor = ...), which is not alarming.  Nonetheless, changing  
pg_class.relfilenode without a lock is unconventional.  Back-patch to  
9.5 (all supported versions), because another fix needs this.  
  
Discussion: https://postgr.es/m/20191226001521.GA1772687@rfd.leadboat.com  

commit   : d60ef94d7639b433a7bf9dd7d48aeb63194235d3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

Remove an obsolete comment from AtEOXact_cleanup().  Restore formatting  
of a comment in struct RelationData, mangled by the pgindent run in  
commit 9af4159fce6654aa0e081b00d02bca40b978745c.  Back-patch to 9.5 (all  
supported versions), because another fix stacks on this.  

commit   : 3ba59ccc896e8877e2fbfb8d4f148904cad5f9b0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 21 Mar 2020 08:48:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 21 Mar 2020 08:48:06 +0530    

This is required as it is no safer for two related processes to perform  
clean up in gin indexes at a time than for unrelated processes to do the  
same.  After acquiring page locks, we can acquire relation extension lock  
but reverse never happens which means these will also not participate in  
deadlock.  So, avoid checking wait edges from this lock.  
  
Currently, the parallel mode is strictly read-only, but after this patch  
we have the infrastructure to allow parallel inserts and parallel copy.  
  
Author: Dilip Kumar, Amit Kapila  
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com  

commit   : a6d7e9fb2816fcd23e5d1e95a52448eb9acf7f6e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Mar 2020 20:19:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Mar 2020 20:19:32 -0400    

The current doc query specified an alias in the FROM clause and used in  
it the target list, but not in the WHERE clause.  
  
Reported-by: axykon@gmail.com  
  
Discussion: https://postgr.es/m/158316348159.30450.16075357948244298217@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 069b750ca764a85324a138c22c3ece5cf13d684f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Mar 2020 18:11:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Mar 2020 18:11:28 -0300    

Noticed by Erik Rijkers before I was able to push the fix.  

commit   : 4e62091341b4a55666a32dd7762f185a1faa54f7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Mar 2020 17:21:00 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Mar 2020 17:21:00 -0300    

Author: Luis Carril  
Reviewed-by: Tomas Vondra, Daniel Gustafsson, Álvaro Herrera  
Discussion: https://postgr.es/m/LEJPR01MB0185A19B2E7C98E5E2A031F5E7F20@LEJPR01MB0185.DEUPRD01.PROD.OUTLOOK.DE  

commit   : 71c2fd0c04a5daaaab5331879e23181bb52334e1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Mar 2020 13:55:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Mar 2020 13:55:15 -0400    

These are disabled by the configure code, so this is just fixing an  
inconsistency in the MSVC code.  
  
Backpatch to all live branches.  

commit   : b03436994bcc4909dd644fd5ae6d9a9acdf30da5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Mar 2020 16:04:15 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Mar 2020 16:04:15 +0100    

Errors (for example I/O errors or disk full) while printing out result  
tables were completely ignored, which could result in silently  
truncated output in scripts, for example.  Fix by adding some basic  
error checking and reporting.  
  
Author: Daniel Verite <daniel@manitou-mail.org>  
Author: David Zhang <david.zhang@highgo.ca>  
Discussion: https://www.postgresql.org/message-id/flat/9a0b3c8d-ee14-4b1d-9d0a-2c993bdabacc@manitou-mail.org  

commit   : 85f6b49c2c53fb1e08d918ec9305faac13cf7ad6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Mar 2020 08:20:56 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Mar 2020 08:20:56 +0530    

This is required as it is no safer for two related processes to extend the  
same relation at a time than for unrelated processes to do the same.  We  
don't acquire a heavyweight lock on any other object after relation  
extension lock which means such a lock can never participate in the  
deadlock cycle.  So, avoid checking wait edges from this lock.  
  
This provides an infrastructure to allow parallel operations like insert,  
copy, etc. which were earlier not possible as parallel group members won't  
conflict for relation extension lock.  
  
Author: Dilip Kumar, Amit Kapila  
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com  

commit   : b27e1b3418b189e1a5aee13cbd09bff94f010a86    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 19 Mar 2020 14:56:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 19 Mar 2020 14:56:56 -0700    

Remove comments that are a throw back to a time when nbtree cared about  
write-ordering dependencies.  The comments are similar to those removed  
by commit 9ee7414e, among others.  

commit   : 2fd6a44ad5744905e9ceacef7aaf698f608e6adb    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Mar 2020 11:20:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Mar 2020 11:20:39 -0700    

This reverts commit e00912e11a9ec2d29274ed8a6465e81385906dc2.  

commit   : 2247a1ea5fabafc11a6deab1c6fe822c9df45bb1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Mar 2020 15:20:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Mar 2020 15:20:55 -0400    

This patch fixes the error message in get_major_server_version() to be  
"could not parse version file", and uses the full file path name, rather  
than just the data directory path.  
  
Also, commit 4109bb5de4 added the cause of the failure to the  "could  
not open" error message, and improved quoting.  This patch backpatches  
the "could not open" cause to PG 12, where it was first widely used, and  
backpatches the quoting fix in that patch to all supported releases.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org  
  
Author: Dagfinn Ilmari Mannsåker  
  
Backpatch-through: 9.5  

commit   : 45452825e5a11f8242a8012853bd2ff81e8b9620    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Mar 2020 21:40:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Mar 2020 21:40:45 +0300    

commit   : 24e2885ee304cb6a94fdfc25a1a108344ed9f4f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Mar 2020 11:43:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Mar 2020 11:43:11 -0400    

This patch adds the pseudo-types anycompatible, anycompatiblearray,  
anycompatiblenonarray, and anycompatiblerange.  They work much like  
anyelement, anyarray, anynonarray, and anyrange respectively, except  
that the actual input values need not match precisely in type.  
Instead, if we can find a common supertype (using the same rules  
as for UNION/CASE type resolution), then the parser automatically  
promotes the input values to that type.  For example,  
"myfunc(anycompatible, anycompatible)" can match a call with one  
integer and one bigint argument, with the integer automatically  
promoted to bigint.  With anyelement in the definition, the user  
would have had to cast the integer explicitly.  
  
The new types also provide a second, independent set of type variables  
for function matching; thus with "myfunc(anyelement, anyelement,  
anycompatible) returns anycompatible" the first two arguments are  
constrained to be the same type, but the third can be some other  
type, and the result has the type of the third argument.  The need  
for more than one set of type variables was foreseen back when we  
first invented the polymorphic types, but we never did anything  
about it.  
  
Pavel Stehule, revised a bit by me  
  
Discussion: https://postgr.es/m/CAFj8pRDna7VqNi8gR+Tt2Ktmz0cq5G93guc3Sbn_NVPLdXAkqA@mail.gmail.com  

commit   : fab13dc50ba5e7a12b474a7366024681bc169ac8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Mar 2020 17:09:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Mar 2020 17:09:00 +0900    

This commit changes pg_basebackup so that it specifies PROGRESS option in  
BASE_BACKUP replication command whether --progress is specified or not.  
This causes the server to estimate the total backup size and report it in  
pg_stat_progress_basebackup.backup_total, by default. This is reasonable  
default because the time required for the estimation would not be so large  
in most cases.  
  
Also this commit adds new option --no-estimate-size to pg_basebackup.  
This option prevents the server from the estimation, and so is useful to  
avoid such estimation time if it's too long.  
  
Author: Fujii Masao  
Reviewed-by: Magnus Hagander, Amit Langote  
Discussion: https://postgr.es/m/CABUevEyDPPSjP7KRvfTXPdqOdY5aWNkqsB5aAXs3bco5ZwtGHg@mail.gmail.com  

commit   : c314c147c0563c9758bdad988ffda8d64daa2db6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Mar 2020 08:17:50 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Mar 2020 08:17:50 +0100    

This by itself doesn't change any functionality but prepares the way  
for having relations other than base tables in publications.  
  
Make arrangements for COPY handling the initial table sync.  For  
non-tables we have to use COPY (SELECT ...) instead of directly  
copying from the table, but then we have to take care to omit  
generated columns from the column list.  
  
Also, remove a hardcoded reference to relkind = 'r' and rely on the  
publisher to send only what it can actually publish, which will be  
correct even in future cross-version scenarios.  
  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : 1d253bae57fcb3e75cdd9cdb2592c5b09cf7e7b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Mar 2020 15:32:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Mar 2020 15:32:55 +0900    

This commit renames RecoveryWalAll and RecoveryWalStream wait events to  
RecoveryWalStream and RecoveryRetrieveRetryInterval, respectively,  
in order to make the names and what they are more consistent. For example,  
previously RecoveryWalAll was reported as a wait event while the recovery  
was waiting for WAL from a stream, and which was confusing because the name  
was very different from the situation where the wait actually could happen.  
  
The names of macro variables for those wait events also are renamed  
accordingly.  
  
This commit also changes the category of RecoveryRetrieveRetryInterval to  
Timeout from Activity because the wait event is reported while waiting based  
on wal_retrieve_retry_interval.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi  
Discussion: https://postgr.es/m/124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.com  

commit   : 72e78d831ab5550c39f2dcc7cc5d44c406ec3dc2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Mar 2020 08:11:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Mar 2020 08:11:45 +0530    

Assert that we don't acquire any other heavyweight lock while holding the  
page lock except for relation extension.  However, these locks are never  
taken in reverse order which implies that page locks will never  
participate in the deadlock cycle.  
  
Similar to relation extension, page locks are also held for a short  
duration, so imposing such a restriction won't hurt.  
  
Author: Dilip Kumar, with few changes by Amit Kapila  
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com  

commit   : 6312c08a291fc34068571ec64ee439f2674d739a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 18 Mar 2020 18:17:37 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 18 Mar 2020 18:17:37 -0700    

Only internal page splits need to call _bt_pgaddtup() instead of  
PageAddItem(), and only for data items, one of which will end up at the  
first offset (or first offset after the high key offset) on the new  
right page.  This data item alone will need to be truncated in  
_bt_pgaddtup().  
  
Since there is no reason why retail inserts ever need to truncate the  
incoming item, use a raw PageAddItem() call there instead.  Even  
_bt_split() uses raw PageAddItem() calls for left page and right page  
high keys.  Clearly the _bt_pgaddtup() shim function wasn't really  
encapsulating anything.  _bt_pgaddtup() should now be thought of as a  
_bt_split() helper function.  
  
Note that the assertions from commit d1e241c2 verify that retail inserts  
never insert an item at an internal page's negative infinity offset.  
This invariant could only ever be violated as a result of a basic logic  
error in nbtinsert.c.  

commit   : d41202f36eed97a4ee68a6a9f5fcca314f12c35d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Mar 2020 09:51:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Mar 2020 09:51:33 +0900    

A comment about switching indisvalid of the new and old indexes swapped  
in REINDEX CONCURRENTLY got this backwards.  
  
Issue introduced by 5dc92b8, the original commit of REINDEX  
CONCURRENTLY.  
  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/20200318143340.GA46897@nol  
Backpatch-through: 12  

commit   : 1f39bce021540fde00990af55b4432c55ef4b3c7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 18 Mar 2020 15:42:02 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 18 Mar 2020 15:42:02 -0700    

While performing hash aggregation, track memory usage when adding new  
groups to a hash table. If the memory usage exceeds work_mem, enter  
"spill mode".  
  
In spill mode, new groups are not created in the hash table(s), but  
existing groups continue to be advanced if input tuples match. Tuples  
that would cause a new group to be created are instead spilled to a  
logical tape to be processed later.  
  
The tuples are spilled in a partitioned fashion. When all tuples from  
the outer plan are processed (either by advancing the group or  
spilling the tuple), finalize and emit the groups from the hash  
table. Then, create new batches of work from the spilled partitions,  
and select one of the saved batches and process it (possibly spilling  
recursively).  
  
Author: Jeff Davis  
Reviewed-by: Tomas Vondra, Adam Lee, Justin Pryzby, Taylor Vesely, Melanie Plageman  
Discussion: https://postgr.es/m/507ac540ec7c20136364b5272acbcd4574aa76ef.camel@j-davis.com  

commit   : e00912e11a9ec2d29274ed8a6465e81385906dc2    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 18 Mar 2020 15:39:14 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 18 Mar 2020 15:39:14 -0700    

An AllocSet doubles the size of allocated blocks (up to maxBlockSize),  
which means that the current block can represent half of the total  
allocated space for the memory context. But the free space in the  
current block may never have been touched, so don't count the  
untouched memory as allocated for the purposes of  
MemoryContextMemAllocated().  
  
Discussion: https://postgr.es/m/ec63d70b668818255486a83ffadc3aec492c1f57.camel@j-davis.com  

commit   : 487e9861d0cf83e9100ad0d0369147db3ef4ea73    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Mar 2020 18:58:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Mar 2020 18:58:05 -0300    

... with the limitation that the tuple must remain in the same  
partition.  
  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/20200227165158.GA2071@alvherre.pgsql  

commit   : b029395f5e616e0f2b1131b2c7ecb6640f30c055    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 18 Mar 2020 14:42:49 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 18 Mar 2020 14:42:49 -0700    

Commit 2b272734, which added the fastpath rightmost leaf page cache  
insert optimization, added code to _bt_doinsert() to handle using and  
invalidating the backend local block cache.  It doesn't seem like a good  
place to handle these low level details, though.  _bt_doinsert() is  
supposed to be a high level function -- it is the main entry point to  
nbtinsert.c.  
  
Restructure the code by placing handling of the rightmost block cache at  
the start of a new _bt_search() shim function, _bt_search_insert().  The  
new function is called from _bt_doinsert(), which uses it as a  
_bt_search() variant that conveniently accepts its BTInsertState state  
as an argument.  _bt_doinsert() no longer needs to directly consider the  
fastpath optimization.  
  
Discussion: https://postgr.es/m/CAH2-Wzk59cxKJRd=rfbyub6-V4yWRjsOYRkUNHBLT1P1GdtCQQ@mail.gmail.com  

commit   : a2b1faa0f279f18517adc1dd969e5f026eb51d33    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Mar 2020 21:20:01 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Mar 2020 21:20:01 +0100    

This will be helpful for a following commit and it's also just  
generally useful, like the other reg* types.  
  
Author: Julien Rouhaud  
Reviewed-by: Thomas Munro and Michael Paquier  
Discussion: https://postgr.es/m/CAEepm%3D0uEQCpfq_%2BLYFBdArCe4Ot98t1aR4eYiYTe%3DyavQygiQ%40mail.gmail.com  

commit   : c31132d87c6315bbbe4b4aa383705aaae2348c0e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 16:48:12 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 16:48:12 +0100    

Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but  
failed to add it to document it properly.  
  
Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>  

commit   : ccaa3569f58796868303629bc2d63ddddb599b38    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 16:41:45 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 16:41:45 +0100    

Since commit 8f321bd16c functional dependencies can handle IN clauses,  
which however introduced a possible (and surprising) inconsistency,  
because IN clauses may be expressed as an OR clause, which are still  
considered incompatible. For example  
  
  a IN (1, 2, 3)  
  
may be rewritten as  
  
  (a = 1 OR a = 2 OR a = 3)  
  
The IN clause will work fine with functional dependencies, but the OR  
clause will force the estimation to fall back to plain per-column  
estimates, possibly introducing significant estimation errors.  
  
This commit recognizes OR clauses equivalent to an IN clause (when all  
arugments are compatible and reference the same attribute) as a special  
case, compatible with functional dependencies. This allows applying  
functional dependencies, just like for IN clauses.  
  
This does not eliminate the difference in estimating the clause itself,  
i.e. IN clause and OR clause still use different formulas. It would be  
possible to change that (for these special OR clauses), but that's not  
really about extended statistics - it was always like this. Moreover the  
errors are usually much smaller compared to ignoring dependencies.  
  
Author: Tomas Vondra  
Reviewed-by: Dean Rasheed  
Discussion: https://www.postgresql.org/message-id/flat/13902317.Eha0YfKkKy%40pierred-pdoc  

commit   : dbe0d9892c338a475c0e791a5e77cff798216d29    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Mar 2020 23:07:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Mar 2020 23:07:17 +0900    

This commit corrects the descriptions of RecoveryWalAll and RecoveryWalStream  
wait events in the documentation.  
  
Back-patch to v10 where those wait events were added.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi  
Discussion: https://postgr.es/m/124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.com  

commit   : 8408e3a557ad26a7e88f867a425b2b9a86c4fa04    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Mar 2020 14:51:37 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Mar 2020 14:51:37 +0100    

Add missing index entries, add missing information on pg_upgrade man  
page, order things alphabetical instead of (apparently) in the order  
they were implemented, reduce repetitiveness a bit.  

commit   : 6f72dbc48bf8a0f4dc3248691355b0688d7aeba2    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 13:38:49 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 18 Mar 2020 13:38:49 +0100    

Reported-by: Thomas Munro  
Discussion: https://www.postgresql.org/message-id/flat/20200113230008.g67iyk4cs3xbnjju@development  

commit   : 1558413432e3dce941af550f1ad0d41790ec6fba    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Mar 2020 18:28:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Mar 2020 18:28:22 +0900    

Commit 773df883e8f7 changed the type of check_option reloption  
from string to enum. But it forgot to update the description of  
the type in the documentation.  
  
Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFvHF4n6yxF390YZgr4Q0Z0c2w0ihu=DLb8ipNOnNcqzQ@mail.gmail.com  

commit   : b4f140869f5da081c27c344587b0ff1a02821776    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Mar 2020 09:27:14 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Mar 2020 09:27:14 +0530    

This will allow to specifying SQLSTATE error code for the errors in the  
missing places.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : fdeeb524b4e28affc527548af389c75e0a99c340    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Mar 2020 11:13:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Mar 2020 11:13:12 +0900    

Introduced by 61d7c7b.  
  
Backpatch-through: 12  

commit   : 15ef6ff4b985276c386adf3e11ebf7f955ea6f1f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Mar 2020 07:20:17 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Mar 2020 07:20:17 +0530    

The only exception to the rule is that we can try to acquire the same  
relation extension lock more than once.  This is allowed as we are not  
creating any new lock for this case.  This restriction implies that the  
relation extension lock won't ever participate in the deadlock cycle  
because we can never wait for any other heavyweight lock after acquiring  
this lock.  
  
Such a restriction is okay for relation extension locks as unlike other  
heavyweight locks these are not held till the transaction end.  These are  
taken for a short duration to extend a particular relation and then  
released.  
  
Author: Dilip Kumar, with few changes by Amit Kapila  
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com  

commit   : b897b3aae6b525922fe3d074d4bdf5f2674954dd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 17 Mar 2020 18:39:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 17 Mar 2020 18:39:26 -0700    

Copying block and offset numbers to local variables in _bt_insertonpg()  
made the code less readable.  Remove the variables.  There is already  
code that conditionally calls BufferGetBlockNumber() in the same block,  
so consistently do it that way instead.  
  
Calling BufferGetBlockNumber() is very cheap, but we might as well avoid  
it when it isn't truly necessary.  It isn't truly necessary for  
_bt_insertonpg() to call BufferGetBlockNumber() in almost all cases.  
  
Spotted while working on a patch that refactors the fastpath rightmost  
leaf page cache optimization, which was added by commit 2b272734.  

commit   : 9b8aa0929390aab1f2f0859016e6110d283732dd    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 18 Mar 2020 12:48:13 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 18 Mar 2020 12:48:13 +1300    

For the semantics to match the epoll implementation, we need a socket to  
continue to appear readable/writable if you wait multiple times without  
doing I/O in between (in Linux terminology: level-triggered rather than  
edge-triggered).  This distinction will be important for later commits.  
Similar to commit 3b790d256f8 for Windows.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com  

commit   : 7bc84a1f304acc9f4705c4178eb362ddce310452    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 18 Mar 2020 12:43:05 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 18 Mar 2020 12:43:05 +1300    

While running under a debugger, macOS's getppid() can return the  
debugger's PID.  That could cause a backend to exit because it falsely  
believed that the postmaster had died, since commit 815c2f09.  
  
Continue to use getppid() as a fast postmaster check after adding the  
postmaster's PID to a kqueue, to close a PID-reuse race, but double  
check that it actually exited by trying to read the pipe.  The new check  
isn't reached in the common case.  
  
Reported-by: Alexander Korotkov <a.korotkov@postgrespro.ru>  
Discussion: https://postgr.es/m/CA%2BhUKGKhAxJ8V8RVwCo6zJaeVrdOG1kFBHGZOOjf6DzW_omeMA%40mail.gmail.com  

commit   : e6c178b5b73ac1fb822829e6d9b99e3fc1129c21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 19:36:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 19:36:41 -0400    

pg_proc.c and pg_aggregate.c had near-duplicate copies of the logic  
to decide whether a function or aggregate's signature is legal.  
This seems like a bad thing even without the problem that the  
upcoming "anycompatible" patch would roughly double the complexity  
of that logic.  Hence, refactor so that the rules are localized  
in new subroutines supplied by parse_coerce.c.  (One could quibble  
about just where to add that code, but putting it beside  
enforce_generic_type_consistency seems not totally unreasonable.)  
  
The fact that the rules are about to change would mandate some  
changes in the wording of the associated error messages in any case.  
I ended up spelling things out in a fairly literal fashion in the  
errdetail messages, eg "A result of type anyelement requires at  
least one input of type anyelement, anyarray, anynonarray, anyenum,  
or anyrange."  Perhaps this is overkill, but once there's more than  
one subgroup of polymorphic types, people might get confused by  
more-abstract messages.  
  
Discussion: https://postgr.es/m/24137.1584139352@sss.pgh.pa.us  

commit   : dbbb55385cf5eb75837eb3eb7ca1f14e2beb5a63    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 17 Mar 2020 15:53:05 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 17 Mar 2020 15:53:05 -0700    

Use a varlistentry id for the deduplicate_items storage parameter that  
is derived from the name of the parameter itself.  
  
This oversight happened because the storage parameter was renamed  
relatively late during the development of the patch that became commit  
0d861bbb.  

commit   : 77ec5affbc44cc0a1d06d4201f0d7c8c79371550    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 18:29:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 18:29:07 -0400    

Ordinarily it's impossible for an actual input of a function to have  
declared type ANYARRAY, since we'd resolve that to a concrete array  
type before doing argument type resolution for the function.  But an  
exception arises for functions applied to certain columns of pg_statistic  
or pg_stats, since we abuse the "anyarray" pseudotype by using it to  
declare those columns.  So parse_coerce.c has to deal with the case.  
  
Previously we allowed an ANYARRAY actual input to match an ANYARRAY  
polymorphic argument, but only if no other argument or result was  
declared ANYELEMENT.  When that logic was written, those were the only  
two polymorphic types, and I fear nobody thought carefully about how it  
ought to extend to the other ones that came along later.  But actually  
it was wrong even then, because if a function has two ANYARRAY  
arguments, it should be able to expect that they have identical element  
types, and we'd not be able to ensure that.  
  
The correct generalization is that we can match an ANYARRAY actual input  
to an ANYARRAY polymorphic argument only if no other argument or result  
is of any polymorphic type, so that no promises are being made about  
element type compatibility.  check_generic_type_consistency can't test  
that condition, but it seems better anyway to accept such matches there  
and then throw an error if needed in enforce_generic_type_consistency.  
That way we can produce a specific error message rather than an  
unintuitive "function does not exist" complaint.  (There's some risk  
perhaps of getting new ambiguous-function complaints, but I think that  
any set of functions for which that could happen would be ambiguous  
against ordinary array columns as well.)  While we're at it, we can  
improve the message that's produced in cases that the code did already  
object to, as shown in the regression test changes.  
  
Also, remove a similar test that got cargo-culted in for ANYRANGE;  
there are no catalog columns of type ANYRANGE, and I hope we never  
create any, so that's not needed.  (It was incomplete anyway.)  
  
While here, update some comments and rearrange the code a bit in  
preparation for upcoming additions of more polymorphic types.  
  
In practical situations I believe this is just exchanging one error  
message for another, hopefully better, one.  So it doesn't seem  
needful to back-patch, even though the mistake is ancient.  
  
Discussion: https://postgr.es/m/21569.1584314271@sss.pgh.pa.us  

commit   : 5d0c2d5eba6b58b3c9955ee41c917f7df8b62746    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Mar 2020 18:18:01 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Mar 2020 18:18:01 -0300    

It devolved into a content-less wrapper over read_local_xlog_page, with  
nothing to add, plus it's easily confused with walsender's  
logical_read_xlog_page.  There doesn't seem to be any reason for it to  
stay.  
  
src/include/replication/logicalfuncs.h becomes empty, so remove it too.  
The prototypes it initially had were absorbed by generated fmgrprotos.h.  
  
Discussion: https://postgr.es/m/20191115214102.GA15616@alvherre.pgsql  

commit   : bcd1c3630095e48bc3b1eb0fc8e8c8a7c851eba1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Mar 2020 16:13:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Mar 2020 16:13:18 -0300    

Commit 9f06d79ef831's replication slot copying failed to  
properly reserve the WAL that the slot is expecting to see  
during DecodingContextFindStartpoint (to set the confirmed_flush  
LSN), so concurrent activity could remove that WAL and cause the  
copy process to error out.  But it doesn't actually *need* that  
WAL anyway: instead of running decode to find confirmed_flush, it  
can be copied from the source slot. Fix this by rearranging things  
to avoid DecodingContextFindStartpoint() (leaving the target slot's  
confirmed_flush_lsn to invalid), and set that up afterwards by copying  
from the target slot's value.  
  
Also ensure the source slot's confirmed_flush_lsn is valid.  
  
Reported-by: Arseny Sher  
Author: Masahiko Sawada, Arseny Sher  
Discussion: https://postgr.es/m/871rr3ohbo.fsf@ars-thinkpad  

commit   : 31d846e0265c2c1415d7910d39d5b259b92184ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 15:05:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 15:05:16 -0400    

I noticed that we completely failed to document the restriction  
that an "anyrange" result type has to be inferred from an "anyrange"  
input.  The docs also were less clear than they could be about the  
relationship between "anyrange" and "anyarray".  
  
It's been like this all along, so back-patch.  

commit   : 9d9784c840f3ac98eb41d021c981eea0fe1735ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 14:54:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 14:54:46 -0400    

It is possible to reach check_sql_fn_retval() with an unresolved  
polymorphic rettype, resulting in an assertion failure as demonstrated  
by one of the added test cases.  However, the code following that  
throws what seems an acceptable error message, so just remove the  
Assert and adjust commentary.  
  
While here, I thought it'd be a good idea to provide some parallel  
tests of SQL-function and PL/pgSQL-function polymorphism behavior.  
Some of these cases are perhaps duplicative of tests elsewhere,  
but we hadn't any organized coverage of the topic AFAICS.  
  
Although that assertion's been wrong all along, it won't have any  
effect in production builds, so I'm not bothering to back-patch.  
  
Discussion: https://postgr.es/m/21569.1584314271@sss.pgh.pa.us  

commit   : 0bc8cebdb889368abdf224aeac8bc197fe4c9ae6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 12:09:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Mar 2020 12:09:26 -0400    

If pkg-config is installed and knows about libxml2, use its information  
rather than asking xml2-config.  Otherwise proceed as before.  This  
patch allows "configure --with-libxml" to succeed on platforms that  
have pkg-config but not xml2-config, which is likely to soon become  
a typical situation.  
  
The old mechanism can be forced by setting XML2_CONFIG explicitly  
(hence, build processes that were already doing so will certainly  
not need adjustment).  Also, it's now possible to set XML2_CFLAGS  
and XML2_LIBS explicitly to override both programs.  
  
There is a small risk of this breaking existing build processes,  
if there are multiple libxml2 installations on the machine and  
pkg-config disagrees with xml2-config about which to use.  The  
only case where that seems really likely is if a builder has tried  
to select a non-default xml2-config by putting it early in his PATH  
rather than setting XML2_CONFIG.  Plan to warn against that in the  
minor release notes.  
  
Back-patch to v10; before that we had no pkg-config infrastructure,  
and it doesn't seem worth adding it for this.  
  
Hugh McMaster and Tom Lane; Peter Eisentraut also made an earlier  
attempt at this, from which I lifted most of the docs changes.  
  
Discussion: https://postgr.es/m/CAN9BcdvfUwc9Yx5015bLH2TOiQ-M+t_NADBSPhMF7dZ=pLa_iw@mail.gmail.com  

commit   : 28e0a103a835aec8b31c897b19b3ceb7d92e7c12    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2020 16:06:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2020 16:06:59 +0900    

Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFQebs4WT5eu3dK4qm_2PurZuvB++8nDvSBG0ebRWmbdg@mail.gmail.com  

commit   : 1429d3f767a05e7a4819f55c5b3ff768862dcf78    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2020 12:06:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2020 12:06:22 +0900    

This commit fixes the comment about SharedHotStandbyActive variable.  
The comment was apparently copy-and-pasted.  
  
Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYEjpqZB9wN2Rwc_RMvDybyYqdbkPuDr1NyxJg4f9yGfMw@mail.gmail.com  

commit   : 41b45576d532ab6ef4a968f78b5b06d700ebf61f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Mar 2020 21:36:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Mar 2020 21:36:53 -0400    

We don't need to manually clean up allocations in a SRF's  
multi_call_memory_ctx, because the SRF_RETURN_DONE infrastructure  
takes care of that (and also ensures that it will happen even if the  
function never gets a final call, which simple manual cleanup cannot  
do).  
  
Hence, the code removed by this patch is a waste of code and cycles.  
Worse, it gives the impression that cleaning up manually is a thing,  
which can lead to more serious errors such as those fixed in  
commits 085b6b667 and b4570d33a.  So we should get rid of it.  
  
These are not quite actual bugs though, so I couldn't muster the  
enthusiasm to back-patch.  Fix in HEAD only.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com  

commit   : b4570d33aa045df330bb325ba8a2cbf02266a555    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Mar 2020 21:05:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Mar 2020 21:05:28 -0400    

This extends the fixes made in commit 085b6b667 to other SRFs with the  
same bug, namely pg_logdir_ls(), pgrowlocks(), pg_timezone_names(),  
pg_ls_dir(), and pg_tablespace_databases().  
  
Also adjust various comments and documentation to warn against  
expecting to clean up resources during a ValuePerCall SRF's final  
call.  
  
Back-patch to all supported branches, since these functions were  
all born broken.  
  
Justin Pryzby, with cosmetic tweaks by me  
  
Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com  

commit   : 113758155c11cf993ca0ecee8856e300a2525a30    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Mar 2020 15:51:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Mar 2020 15:51:06 -0700    

Oversight in commit d2086b08b02.  

commit   : 8b6d94cf6c8319bfd6bebf8b863a5db586c19c3b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 19:12:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 19:12:14 -0300    

It's strange that a directory-listing function does not list all entries  
in a directory, so let's at least document it.  This involves  
  
pg_ls_logdir  
pg_ls_waldir  
pg_ls_archive_statusdir  
pg_ls_tmpdir  
  
Backpatch as far back as it applies cleanly (and as far as as each  
function exists).  REL_10_STABLE uses different wording, but hopefully  
people are not reading docs so old to write new apps anyway.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200305161838.GJ684@telsasoft.com  

commit   : b234b567ed740aae368672670d8d03640e884f1f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 18:38:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 18:38:28 -0300    

I forgot to update it per last-minute edits leading to commit  
2f9661311b83.  Reported by Mark Dilger.  
  
Discussion: https://postgr.es/m/DA9A5554-AADD-4F33-96F9-A1066EC9CAB5@enterprisedb.com>  

commit   : 046001fe3cf59e19b2e8c24b82fb2e9b8ab6edd4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 16:27:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Mar 2020 16:27:13 -0300    

Introduced by b08dee24a557.  Noted by Coverity.  

commit   : 013c1f6af6c5017d97b1268cf9a5fa3d0575eecb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Mar 2020 12:00:10 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Mar 2020 12:00:10 -0700    

Refactor nbtinsert.c so that the final itemsz of each new non-pivot  
tuple (the MAXALIGN()'d size) is determined once.  Most of the functions  
used by leaf page inserts used the insertstate.itemsz value already.  
This commit makes everything use insertstate.itemsz as standard  
practice.  The goal is to decouple tuple size from "effective" tuple  
size.  Making this distinction isn't truly necessary right now, but that  
might change in the future.  
  
Also explain why we consistently apply MAXALIGN() to get an effective  
index tuple size.  This was rather unclear, in part because it isn't  
actually strictly necessary right now.  

commit   : fc34b0d9de27ab5ac2887da00b3892bdabd89e45    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 16 Mar 2020 12:31:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 16 Mar 2020 12:31:34 +1300    

Introduce a GUC and a tablespace option to control I/O prefetching, much  
like effective_io_concurrency, but for work that is done on behalf of  
many client sessions.  
  
Use the new setting in heapam.c instead of the hard-coded formula  
effective_io_concurrency + 10 introduced by commit 558a9165e08.  Go with  
a default value of 10 for now, because it's a round number pretty close  
to the value used for that existing case.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com  

commit   : b09ff53667ffc986371ec8ffa372916ad460220d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 16 Mar 2020 11:43:18 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 16 Mar 2020 11:43:18 +1300    

The effective_io_concurrency GUC and equivalent tablespace option were  
previously passed through a formula based on a theory about RAID  
spindles and probabilities, to arrive at the number of pages to prefetch  
in bitmap heap scans.  Tomas Vondra, Andres Freund and others argued  
that it was anachronistic and hard to justify, and commit 558a9165e08  
already started down the path of bypassing it in new code.  We agreed to  
drop that logic and use the value directly.  
  
For the default setting of 1, there is no change in effect.  Higher  
settings can be converted from the old meaning to the new with:  
  
  select round(sum(OLD / n::float)) from generate_series(1, OLD) s(n);  
  
We might want to consider renaming the GUC before the next release given  
the change in meaning, but it's not clear that many users had set it  
very carefully anyway.  That decision is deferred for now.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com  

commit   : f207bb0b8f13999c91b405a2e6c8526225470816    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 15 Mar 2020 20:53:12 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 15 Mar 2020 20:53:12 -0700    

Relocate _bt_newroot() prototype, so that the order that prototypes  
appear in matches the order that the functions are defined in.  

commit   : 70a7b4776be4e776221e578d8ca53b2b9f8118c0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 15 Mar 2020 11:20:21 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 15 Mar 2020 11:20:21 +0100    

The backend type, which corresponds to what  
pg_stat_activity.backend_type shows, is added as a column to the  
csvlog and can optionally be added to log_line_prefix using the new %b  
placeholder.  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://www.postgresql.org/message-id/flat/c65e5196-4f04-4ead-9353-6088c19615a3@2ndquadrant.com  

commit   : d8cfa82d51f812f886d06bdc7bb73470e55d74b7    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 23:04:56 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 23:04:56 +0100    

The regression tests for extended statistics were not testing a couple  
of important cases for the MCV lists:  
  
  * IS NOT NULL clauses - We did have queries with IS NULL clauses, but  
    not the negative case.  
  
  * clauses with variable on the right - All the clauses had the Var on  
    the left, i.e. (Var op Const), so this adds (Const op Var) too.  
  
  * columns with fixed-length types passed by reference - All columns  
    were using either by-value or varlena types, so add a test with  
    UUID columns too. This matters for (de)serialization.  
  
  * NULL-only dimension - When one of the columns contains only NULL  
    values, we treat it a a special case during (de)serialization.  
  
  * arrays containing NULL - When the constant parameter contains NULL  
    value, we need to handle it correctly during estimation, for all  
    IN, ANY and ALL clauses.  
  
Discussion: https://www.postgresql.org/message-id/flat/20200113230008.g67iyk4cs3xbnjju@development  
Author: Tomas Vondra  

commit   : f9696782c70168e575c0f2d17a1cfe71847fef3d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 23:02:55 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 23:02:55 +0100    

The regression tests for functional dependencies were only using clauses  
of the form (Var op Const), i.e. with Var on the left side. This adds  
a couple of queries with Var on the right, to test other code paths.  
  
It also prints one of the functional dependencies, to test the data type  
output function. The functional dependencies are "perfect" with degree  
of 1.0 so this should be stable.  
  
Discussion: https://www.postgresql.org/message-id/flat/20200113230008.g67iyk4cs3xbnjju@development  
Author: Tomas Vondra  

commit   : 87c9c2571c8146f1594830072253ba39e62ccbc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2020 15:31:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2020 15:31:44 -0400    

Commit a5954de10 replaced a lot of manually-coded stub I/O routines  
with code generated by macros.  That was a good idea but it didn't  
go far enough, because there were still manually-coded stub input  
routines for types that had live output routines.  Refactor the  
macro so that we can generate just a stub input routine at need.  
  
Also create similar macros to generate stub binary I/O routines,  
since we have some of those now.  The only stub functions that remain  
hand-coded are shell_in() and shell_out(), which need to be separate  
because they use different error messages.  
  
While here, rearrange the commentary to discuss each type not each  
function.  This provides a better way to explain the *why* of which  
types need which support, rather than just duplicatively annotating  
the functions.  
  
Discussion: https://postgr.es/m/24137.1584139352@sss.pgh.pa.us  

commit   : 4dbcb3f844eca4a401ce06aa2781bd9a9be433e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2020 14:42:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2020 14:42:22 -0400    

resolve_polymorphic_tupdesc() and resolve_polymorphic_argtypes() failed to  
cover the case of having to resolve anyarray given only an anyrange input.  
The bug was masked if anyelement was also used (as either input or  
output), which probably helps account for our not having noticed.  
  
While looking at this I noticed that resolve_generic_type() would produce  
the wrong answer if asked to make that same resolution.  ISTM that  
resolve_generic_type() is confusingly defined and overly complex, so  
rather than fix it, let's just make funcapi.c do the specific lookups  
it requires for itself.  
  
With this change, resolve_generic_type() is not used anywhere, so remove  
it in HEAD.  In the back branches, leave it alone (complete with bug)  
just in case any external code is using it.  
  
While we're here, make some other refactoring adjustments in funcapi.c  
with an eye to upcoming future expansion of the set of polymorphic types:  
  
* Simplify quick-exit tests by adding an overall have_polymorphic_result  
flag.  This is about a wash now but will be a win when there are more  
flags.  
  
* Reduce duplication of code between resolve_polymorphic_tupdesc() and  
resolve_polymorphic_argtypes().  
  
* Don't bother to validate correct matching of anynonarray or anyenum;  
the parser should have done that, and even if it didn't, just doing  
"return false" here would lead to a very confusing, off-point error  
message.  (Really, "return false" in these two functions should only  
occur if the call_expr isn't supplied or we can't obtain data type  
info from it.)  
  
* For the same reason, throw an elog rather than "return false" if  
we fail to resolve a polymorphic type.  
  
The bug's been there since we added anyrange, so back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/6093.1584202130@sss.pgh.pa.us  

commit   : e83daa7e331e0718bb254ab685f2ed95df423554    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 14:56:37 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 14:56:37 +0100    

Commit 8f321bd16c added support for estimating ScalarArrayOpExpr clauses  
(IN/ANY) clauses using functional dependencies. There's no good reason  
not to support estimation of these clauses using multi-variate MCV lists  
too, so this commits implements that. That makes the behavior consistent  
and MCV lists can estimate all variants (ANY/ALL, inequalities, ...).  
  
Author: Tomas Vondra  
Review: Dean Rasheed  
Discussion: https://www.postgresql.org/message-id/flat/13902317.Eha0YfKkKy%40pierred-pdoc  

commit   : 8f321bd16cdb11307f17007eb3c55b65d7d323ef    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 14:55:59 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2020 14:55:59 +0100    

Until now functional dependencies supported only simple equality clauses  
and clauses that can be trivially translated to equalities. This commit  
allows estimation of some ScalarArrayOpExpr (IN/ANY) clauses.  
  
For IN clauses we can do this thanks to using operator with equality  
semantics, which means an IN clause  
  
    WHERE c IN (1, 2, ..., N)  
  
can be translated to  
  
    WHERE (c = 1 OR c = 2 OR ... OR c = N)  
  
IN clauses are now considered compatible with functional dependencies,  
and rely on the same assumption of consistency of queries with data  
(which is an assumption we already used for simple equality clauses).  
This applies also to ALL clauses with an equality operator, which can be  
considered equivalent to IN clause.  
  
ALL clauses are still considered incompatible, although there's some  
discussion about maybe relaxing this in the future.  
  
Author: Pierre Ducroquet  
Reviewed-by: Tomas Vondra, Dean Rasheed  
Discussion: https://www.postgresql.org/message-id/flat/13902317.Eha0YfKkKy%40pierred-pdoc  

commit   : dbf95c843a3d66cf9a692f5937a1bec4f2261035    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Mar 2020 12:49:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Mar 2020 12:49:10 -0400    

This should of course be just "PG_ARGISNULL()".  
  
Also reorder a couple of paras to make the discussion of PG_ARGISNULL  
less disjointed.  
  
Back-patch to v10 where the error was introduced.  
  
Laurenz Albe and Tom Lane, per an anonymous docs comment  
  
Discussion: https://postgr.es/m/158399487096.5708.10696365251766477013@wrigleys.postgresql.org  

commit   : 340de72780e4eb769d5cf052b03084808bac476a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Mar 2020 15:45:37 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Mar 2020 15:45:37 +0100    

FOP issues warnings about them.  These aren't even used, so just  
remove them.  For the ones that are actually used, we'll come up with  
a different solution.  
  
Discussion: https://www.postgresql.org/message-id/flat/e29b580e-79ab-a371-5ea4-6946e4d3af0b%402ndQuadrant.com  

commit   : d90bd24391fdde2b73906e16052821c9e3c1ce82    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    

Use the new MyBackendType instead.  More similar changes for other "am  
something" variables are possible.  This one was just particularly  
simple.  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c65e5196-4f04-4ead-9353-6088c19615a3@2ndquadrant.com  

commit   : 8e8a0becb335529c66a9f82f88e1419e49b458ae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    

Add a new global variable MyBackendType that uses the same BackendType  
enum that was previously only used by the stats collector.  That way  
several duplicate ways of checking what type a particular process is  
can be simplified.  Since it's no longer just for stats, move to  
miscinit.c and rename existing functions to match the expanded  
purpose.  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c65e5196-4f04-4ead-9353-6088c19615a3@2ndquadrant.com  

commit   : 1cc9c2412cc9a2fbe6a381170097d315fd40ccca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Mar 2020 11:28:11 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Mar 2020 11:28:11 +0100    

If an index was explicitly set as replica identity index, this setting  
was lost when a table was rewritten by ALTER TABLE.  Because this  
setting is part of pg_index but actually controlled by ALTER  
TABLE (not part of CREATE INDEX, say), we have to do some extra work  
to restore it.  
  
Based-on-patch-by: Quan Zongliang <quanzongliang@gmail.com>  
Reviewed-by: Euler Taveira <euler.taveira@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c70fcab2-4866-0d9f-1d01-e75e189db342@gmail.com  

commit   : b7f64c64d3262c309e2c5e8c11fd111b1dbd1a4a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2020 15:04:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2020 15:04:11 +0900    

This commit refactors and simplifies the definitions of StaticAssertStmt,  
StaticAssertExpr and StaticAssertDecl.  By unifying the C and C++  
fallback implementations, this reduces the number of different  
implementations from four to three.  
  
Author: Michael Paquier  
Reviewed-by: Georgios Kokolatos, Tom Lane  
Discussion: https://postgr.es/m/20200204081503.GF2287@paquier.xyz  

commit   : a029a0641cce002acbb5e8ac6ec5533e599a9aea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Mar 2020 18:23:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Mar 2020 18:23:57 -0400    

I forgot that the WAL directory might hold other files besides WAL  
segments, notably including new segments still being filled.  
That means a blind test for the first file's size being 16MB can  
fail.  Restrict based on file name length to make it more robust.  
  
Per buildfarm.  

commit   : b08dee24a5574ba6657d238b91c10f1f8e2608f8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Mar 2020 16:54:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Mar 2020 16:54:54 -0300    

pg_dump is oblivious to this kind of dependency, so they're lost on  
dump/restores (and pg_upgrade).  Have pg_dump emit ALTER lines so that  
they're preserved.  Add some pg_dump tests for the whole thing, also.  
  
Reviewed-by: Tom Lane (offlist)  
Reviewed-by: Ibrar Ahmed  
Reviewed-by: Ahsan Hadi (who also reviewed commit 899a04f5ed61)  
Discussion: https://postgr.es/m/20200217225333.GA30974@alvherre.pgsql  

commit   : 085b6b6679e73b9b386f209b4d625c7bc60597c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Mar 2020 15:27:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Mar 2020 15:27:59 -0400    

This coding technique is undesirable because (a) it leaks the FD for  
the rest of the transaction if the SRF is not run to completion, and  
(b) allocated FDs are a scarce resource, but multiple interleaved  
uses of the relevant functions could eat many such FDs.  
  
In v11 and later, a query such as "SELECT pg_ls_waldir() LIMIT 1"  
yields a warning about the leaked FD, and the only reason there's  
no warning in earlier branches is that fd.c didn't whine about such  
leaks before commit 9cb7db3f0.  Even disregarding the warning, it  
wouldn't be too hard to run a backend out of FDs with careless use  
of these SQL functions.  
  
Hence, rewrite the function so that it reads the directory within  
a single call, returning the results as a tuplestore rather than  
via value-per-call mode.  
  
There are half a dozen other built-in SRFs with similar problems,  
but let's fix this one to start with, just to see if the buildfarm  
finds anything wrong with the code.  
  
In passing, fix bogus error report for stat() failure: it was  
whining about the directory when it should be fingering the  
individual file.  Doubtless a copy-and-paste error.  
  
Back-patch to v10 where this function was added.  
  
Justin Pryzby, with cosmetic tweaks and test cases by me  
  
Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com  

commit   : bf68b79e50e3359accc85c94fa23cc03abb9350a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 16:36:40 +0100    

The init_ps_display() arguments were mostly lies by now, so to match  
typical usage, just use one argument and let the caller assemble it  
from multiple sources if necessary.  The only user of the additional  
arguments is BackendInitialize(), which was already doing string  
assembly on the caller side anyway.  
  
Remove the second argument of set_ps_display() ("force") and just  
handle that in init_ps_display() internally.  
  
BackendInitialize() also used to set the initial status as  
"authentication", but that was very far from where authentication  
actually happened.  So now it's set to "initializing" and then  
"authentication" just before the actual call to  
ClientAuthentication().  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c65e5196-4f04-4ead-9353-6088c19615a3@2ndquadrant.com  

commit   : 899a04f5ed61c3db7a2bd84957ecf530c09fd05a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Mar 2020 11:04:59 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Mar 2020 11:04:59 -0300    

If the command is attempted for an extension that the object already  
depends on, silently do nothing.  
  
In particular, this means that if a database containing multiple such  
entries is dumped, the restore will silently do the right thing and  
record just the first one.  (At least, in a world where pg_dump does  
dump such entries -- which it doesn't currently, but it will.)  
  
Backpatch to 9.6, where this kind of dependency was introduced.  
  
Reviewed-by: Ibrar Ahmed, Tom Lane (offlist)  
Discussion: https://postgr.es/m/20200217225333.GA30974@alvherre.pgsql  

commit   : 1c918381814ca6ff976aab2bf130b0c582ca30e4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 13:51:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 13:51:55 +0100    

The code around InitPostmasterChild() from commit 31c453165b5 somehow  
ended up in the middle of a block of code related to "User ID state".  
Move it into its own block instead.  

commit   : aaa3aeddee51dd0058d38469907865052706a590    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 10:58:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Mar 2020 10:58:02 +0100    

Previously, hard links were not used on Windows and Cygwin, but they  
support them just fine in currently supported OS versions, so we can  
use them there as well.  
  
Since all supported platforms now support hard links, we can remove  
the alternative code paths.  
  
Rename durable_link_or_rename() to durable_rename_excl() to make the  
purpose more clear without referencing the implementation details.  
  
Discussion: https://www.postgresql.org/message-id/flat/72fff73f-dc9c-4ef4-83e8-d2e60c98df48%402ndquadrant.com  

commit   : d114cc538715e14d29d6de8b6ea1a1d5d3e0edb4    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 11 Mar 2020 12:00:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 11 Mar 2020 12:00:31 +0300    

This commit eliminates lossiness in check for missing parent downlinks in  
B-tree.  Instead of collecting lossy bitmap, we check for missing downlinks  
while visiting child pages referenced by downlinks of target level.  We  
traverse from previous child page to the subsequent child page by right links.  
Intermediate pages are candidates to have lost parent downlinks.  
  
Also this commit introduces matching of child high key to the pivot key of  
it's parent.  
  
Discussion: https://postgr.es/m/CAPpHfduoF-c4RhOyOm%3D4-Y367%2B8txq9Q6iM_ty0OYc8si1Abww%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  

commit   : a88a285c7e343502b55204a211818d12b1b7d6ff    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 18:03:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 18:03:56 -0700    

Oversight in commit 0d861bbb702.  

commit   : 39eabec90451d8badbba9b3e938d6d05432a0517    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 17:25:47 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 17:25:47 -0700    

Commit 074251db added an assertion that verified the fastpath/rightmost  
page insert optimization's assumption about free space: There should  
always be enough free space on the page to insert the new item without  
splitting the page.  Otherwise, we end up using the "concurrent root  
page split" phony/fake stack path in _bt_insert_parent().  This does not  
lead to incorrect behavior, but it is likely to be far slower than  
simply using the regular _bt_search() path.  The assertion catches  
serious performance bugs that would probably take a long time to detect  
any other way.  
  
It seems much more natural to make this assertion just before the point  
that we generate a fake/phony descent stack.  Move the assert there.  
This also makes _bt_insertonpg() a bit more readable.  

commit   : c8e8b2f9dfee21fa4ef1ec7da5c10e6ef706df36    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 17:34:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 17:34:01 -0400    

Fix up some imprecise comments and poor markup from ba79cb5dc.  Also try  
to convert the documentation of log_min_duration_sample and friends into  
passable English.  

commit   : d1e241c22602a5369b54e29b7430553445f6a52b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 14:15:41 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 10 Mar 2020 14:15:41 -0700    

Only a very basic logic bug in a _bt_insertonpg() caller could lead to a  
violation of this invariant.  Besides, any newitemoff used for an  
internal page is sanitized using other "can't happen" errors in  
_bt_getstackbuf() or its callers, before _bt_insertonpg() even gets  
called.  
  
Also, move the error/assertion from the insert-without-split path of  
_bt_insertonpg() to the top of the same function.  There is no reason  
why this invariant only applies to insertions that happen to not result  
in a page split; cover every insertion.  The assertion naturally belongs  
next to the existing generic assertions that document relatively  
high-level invariants for the item being inserted.  

commit   : cacef172237fd3426b578f81b7414c0de56cbaaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 14:54:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 14:54:00 -0400    

Since the documentation about LIKE doesn't say that a copied constraint  
has properties different from the original, it seems that ignoring  
a NO INHERIT property doesn't meet the principle of least surprise.  
So make it copy that.  
  
(Note, however, that we still don't copy a NOT VALID property;  
CREATE TABLE offers no way to do that, plus it seems pointless.)  
  
Arguably this is a bug fix; but no back-patch, as it seems barely  
possible somebody is depending on the current behavior.  
  
Ildar Musin and Chris Travers; reviewed by Amit Langote and myself  
  
Discussion: https://postgr.es/m/CAONYFtMC6C+3AWCVp7Yd8H87Zn0GxG1_iQG6_bQKbaqYZY0=-g@mail.gmail.com  

commit   : dbf05a14399430751e54cd0b4bd8fb0e4f1fb309    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 12:46:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 12:46:07 -0400    

Apparently not all shells handle nested quotes quite the same.  
But we don't need the inner double quotes in this case, so just  
drop them.  
  
Discussion: https://postgr.es/m/50ecb345-4dc5-1f7d-64ca-7018195fcc8d@2ndquadrant.com  

commit   : d01f03a495294f726001a90ec27a675428d9fc45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 12:29:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Mar 2020 12:29:59 -0400    

Previously, this code just smashed all types of DefElem values to  
strings, cavalierly reasoning that nobody would care.  But in point of  
fact, most of the defGetFoo functions do distinguish among different  
input syntaxes; for instance defGetBoolean will accept 1 as an integer  
but not "1" as a string.  This led to CREATE/ALTER TEXT SEARCH  
DICTIONARY accepting 0 and 1 as values for boolean dictionary  
properties, only to have the dictionary fail at runtime.  
  
We can upgrade this behavior by teaching serialize_deflist that it  
does not need to quote T_Integer or T_Float nodes' values on output,  
and then teaching deserialize_deflist to restore unquoted integer or  
float values as the appropriate node type.  This should not break  
anything using pg_ts_dict.dictinitoption, since that field is just  
defined as being something valid to include in CREATE TEXT SEARCH  
DICTIONARY.  
  
deserialize_deflist is also used to parse the options arguments  
for the ts_headline family of functions, but so far as I can see  
this won't cause any problems there either: the only consumer of  
that output is prsd_headline which always uses defGetString.  
(Really that's a bad idea, but I won't risk changing it here.)  
  
This is surely a bug fix, but given the lack of field complaints  
I don't think it's necessary to back-patch.  
  
Discussion: https://postgr.es/m/CAMkU=1xRcs_BUPzR0+V3WndaCAv0E_m3h6aUEJ8NF-sY1nnHsw@mail.gmail.com  

commit   : 40b3e2c201af10c27a2c4c5bfcd029026b4cdff3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Mar 2020 11:28:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Mar 2020 11:28:23 -0300    

This catalog-handling code was previously together with the rest of  
CastCreate() in src/backend/commands/functioncmds.c.  A future patch  
will need a way to add casts internally, so this will be useful to have  
separate.  
  
Also, move the nearby get_cast_oid() function from functioncmds.c to  
lsyscache.c, which seems a more natural place for it.  
  
Author: Paul Jungwirth, minor edits by Álvaro  
Discussion: https://postgr.es/m/20200309210003.GA19992@alvherre.pgsql  

commit   : 0a42a2e9ce8481a024d085f2cc526a366db8df59    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 11:20:38 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 11:20:38 +0100    

This removes another relic from the old nmake-based Windows build.  
version_stamp.pl put version number information into win32ver.rc.  But  
win32ver.rc already gets other version number information from the  
preprocessor at build time, so it would make more sense if all version  
number information would be handled in the same way and we don't have  
two places that do it.  
  
What we need for this is having the major version number and the minor  
version number as separate integer symbols.  Both configure and  
Solution.pm already have that logic, because they compute  
PG_VERSION_NUM.  So we just keep all the logic there now.  Put the  
minor version number into a new symbol PG_MINORVERSION_NUM.  Also, add  
a symbol PG_MAJORVERSION_NUM, which is a number, alongside the  
existing PG_MAJORVERSION, which is a string.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/1ee46ac4-a9b2-4531-bf54-5ec2e374634d@2ndquadrant.com  

commit   : 3c173a53a825075f3efe32b9917eff5063e81f4d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 10:22:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 10:22:52 +0100    

The need for this was removed by  
8b9e9644dc6a9bd4b7a97950e6212f63880cf18b.  
  
A number of files now need to include utils/acl.h or  
parser/parse_node.h explicitly where they previously got it indirectly  
somehow.  
  
Since parser/parse_node.h already includes nodes/parsenodes.h, the  
latter is then removed where the former was added.  Also, remove  
nodes/pg_list.h from objectaddress.h, since that's included via  
nodes/parsenodes.h.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/7601e258-26b2-8481-36d0-dc9dca6f28f1%402ndquadrant.com  

commit   : 17b9e7f9fe238eeb5f6b40061b444ebf28d9e06f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 08:42:59 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Mar 2020 08:42:59 +0100    

When a partitioned table is added to a publication, changes of all of  
its partitions (current or future) are published via that publication.  
  
This change only affects which tables a publication considers as its  
members.  The receiving side still sees the data coming from the  
individual leaf partitions.  So existing restrictions that partition  
hierarchies can only be replicated one-to-one are not changed by this.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : 61d7c7bce3686ec02bd64abac742dd35ed9b9b01    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Mar 2020 15:38:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Mar 2020 15:38:17 +0900    

Such indexes can only be duplicated leftovers of a previously failed  
REINDEX CONCURRENTLY command, and a valid equivalent is guaranteed to  
exist.  As toast indexes can only be dropped if invalid, reindexing  
these would lead to useless duplicated indexes that can't be dropped  
anymore, except if the parent relation is dropped.  
  
Thanks to Justin Pryzby for reminding that this problem was reported  
long ago during the review of the original patch of REINDEX  
CONCURRENTLY, but the issue was never addressed.  
  
Reported-by: Sergei Kornilov, Justin Pryzby  
Author: Julien Rouhaud  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/36712441546604286%40sas1-890ba5c2334a.qloud-c.yandex.net  
Discussion: https://postgr.es/m/20200216190835.GA21832@telsasoft.com  
Backpatch-through: 12  

commit   : 71e0d0a73773b3985db658d3c5366ce5ceef76ae    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 10 Mar 2020 09:41:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 10 Mar 2020 09:41:44 +0900    

This commit replaces 0 used as an initial value of XLogSource variable,  
with XLOG_FROM_ANY. Also this commit changes those variable so that  
XLogSource instead of int is used as the type for them. These changes  
are for code readability and debugger-friendliness.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20200227.124830.2197604521555566121.horikyota.ntt@gmail.com  

commit   : 8728b2c703573c6cbb431e01e228ae489117f974    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Mar 2020 14:58:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Mar 2020 14:58:11 -0400    

Previously, event triggers were restored just after regular triggers  
(and FK constraints, which are basically triggers).  This is risky  
since an event trigger, once installed, could interfere with subsequent  
restore commands.  Worse, because event triggers don't have any  
particular dependencies on any post-data objects, a parallel restore  
would consider them eligible to be restored the moment the post-data  
phase starts, allowing them to also interfere with restoration of a  
whole bunch of objects that would have been restored before them in  
a serial restore.  There's no way to completely remove the risk of a  
misguided event trigger breaking the restore, since if nothing else  
it could break other event triggers.  But we can certainly push them  
to later in the process to minimize the hazard.  
  
To fix, tweak the RestorePass mechanism introduced by commit 3eb9a5e7c  
so that event triggers are handled as part of the post-ACL processing  
pass (renaming the "REFRESH" pass to "POST_ACL" to reflect its more  
general use).  This will cause them to restore after everything except  
matview refreshes, which seems OK since matview refreshes really ought  
to run in the post-restore state of the database.  In a parallel  
restore, event triggers and matview refreshes might be intermixed,  
but that seems all right as well.  
  
Also update the code and comments in pg_dump_sort.c so that its idea  
of how things are sorted agrees with what actually happens due to  
the RestorePass mechanism.  This is mostly cosmetic: it'll affect the  
order of objects in a dump's TOC, but not the actual restore order.  
But not changing that would be quite confusing to somebody reading  
the code.  
  
Back-patch to all supported branches.  
  
Fabrízio de Royes Mello, tweaked a bit by me  
  
Discussion: https://postgr.es/m/CAFcNs+ow1hmFox8P--3GSdtwz-S3Binb6ZmoP6Vk+Xg=K6eZNA@mail.gmail.com  

commit   : 24d85952a57b16090ca8ad9cf800fbdd9ddd104f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Mar 2020 17:28:53 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Mar 2020 17:28:53 -0800    

Increases the number of tapes in a logical tape set. This will be  
important for disk-based hash aggregation, because the maximum number  
of tapes is not known ahead of time.  
  
While discussing this change, it was observed to regress the  
performance of Sort for at least one test case. The performance  
regression was because some versions of GCC switch to an inlined  
version of memcpy() in LogicalTapeWrite() after this change. No  
performance regression for clang was observed.  
  
Because the regression is due to an arbitrary decision by the  
compiler, I decided it shouldn't hold up this change. If it needs to  
be fixed, we can find a workaround.  
  
Author: Adam Lee, Jeff Davis  
Discussion: https://postgr.es/m/e54bfec11c59689890f277722aaaabd05f78e22c.camel%40j-davis.com  

commit   : 17d3fcdc39577b1e43624392c25e5384da42e522    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 10 Mar 2020 00:14:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 10 Mar 2020 00:14:43 +0900    

Previously "waiting" could appear twice via PS in case of lock conflict  
in hot standby mode. Specifically this issue happend when the delay  
in WAL application determined by max_standby_archive_delay and  
max_standby_streaming_delay had passed but it took more than 500 msec  
to cancel all the conflicting transactions. Especially we can observe this  
easily by setting those delay parameters to -1.  
  
The cause of this issue was that WaitOnLock() and  
ResolveRecoveryConflictWithVirtualXIDs() added "waiting" to  
the process title in that case. This commit prevents  
ResolveRecoveryConflictWithVirtualXIDs() from reporting waiting  
in case of lock conflict, to fix the bug.  
  
Back-patch to all back branches.  
  
Author: Masahiko Sawada  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CA+fd4k4mXWTwfQLS3RPwGr4xnfAEs1ysFfgYHvmmoUgv6Zxvmg@mail.gmail.com  

commit   : 71d60e2aa05157efec28393b15c0b0b9fc1b210c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Mar 2020 09:22:22 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Mar 2020 09:22:22 +0100    

This allows a trigger function to determine for an UPDATE trigger  
which columns were actually updated.  This allows some optimizations  
in generic trigger functions such as lo_manage and  
tsvector_update_trigger.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/flat/11c5f156-67a9-0fb5-8200-2a8018eb2e0c@2ndquadrant.com  

commit   : 8f152b6c50c764d4c300e73a535da88cd1b18fa5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Feb 2020 10:12:10 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Feb 2020 10:12:10 +0100    

Initialize TriggerData to 0 for the whole struct together, instead of  
each field separately.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/flat/11c5f156-67a9-0fb5-8200-2a8018eb2e0c@2ndquadrant.com  

commit   : ef34ab42a85968f3ab4c8e490b77dfb3565dd5e7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2020 15:31:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2020 15:31:31 +0900    

At the end of recovery, standby mode is turned off to re-fetch the last  
valid record from archive or pg_wal. Previously, if recovery target was  
reached and standby mode was turned off while the current WAL source  
was stream, recovery could try to retrieve WAL file containing the last  
valid record unexpectedly from stream even though not in standby mode.  
This caused an assertion failure. That is, the assertion test confirms that  
WAL file should not be retrieved from stream if standby mode is not true.  
  
This commit moves back the current WAL source to archive if it's stream  
even though not in standby mode, to avoid that assertion failure.  
  
This issue doesn't cause the server to crash when built with assertion  
disabled. In this case, the attempt to retrieve WAL file from stream not  
in standby mode just fails. And then recovery tries to retrieve WAL file  
from archive or pg_wal.  
  
Back-patch to all supported branches.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20200227.124830.2197604521555566121.horikyota.ntt@gmail.com  

commit   : d9249441efc5b4adc5b1a71f3d16538c68e198fc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2020 11:41:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2020 11:41:31 +0900    

This commit changes the GUC ssl_passphrase_command so that  
it's examinable by only superuser and a member of pg_read_all_settings.  
Per discussion, we determined to do this because the parameter may  
contain a sensitive informtaion like a passphrase itself.  
  
Author: Insung Moon  
Reviewed-by: Keisuke Kuroda  
Discussion: https://postgr.es/m/CAEMmqBuHVGayc+QkYKgx3gWSdqwTAQGw+0DYn3WhcX-eNa2ntA@mail.gmail.com  

commit   : 5aaa584f819e2d8d2fb23cdf2174ce6e5628e1f5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2020 10:53:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2020 10:53:22 +0900    

This addresses a couple of issues in the documentation:  
- Description of PG_COLOR was missing for some tools (pg_archivecleanup  
and pg_test_fsync), while the other descriptions had grammar mistakes.  
- pgbench supports more environment variables: PGUSER, PGHOST and  
PGPORT.  
- vacuumlo, oid2name and pgbench support coloring (HEAD only)  
  
Author: Michael Paquier  
Reviewed-by: Fabien Coelho, Daniel Gustafsson, Juan José Santamaría  
Flecha  
Discussion: https://postgr.es/m/20200304075418.GJ2593@paquier.xyz  
Backpatch-through: 12  

commit   : 806eb92c018102da9514443ad19160c7b1841062    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2020 18:35:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2020 18:35:06 -0400    

Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1xRcs_BUPzR0+V3WndaCAv0E_m3h6aUEJ8NF-sY1nnHsw@mail.gmail.com  

commit   : 38ce06c37e9cc8fec9125262b129602c2274f344    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2020 15:09:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2020 15:09:14 -0400    

Seems like a good idea in view of 006517432 and addd034ae.  
  
Michael Paquier, Tom Lane  
  
Discussion: https://postgr.es/m/20200306075230.GA118430@paquier.xyz  

commit   : b0b5e20cd8d1a58a8782d5dc806a5232db116e2f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Mar 2020 13:32:25 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Mar 2020 13:32:25 +0300    

This commit provides psql commands for listing operator classes, operator  
families and its contents in psql.  New commands will be useful for exploring  
capabilities of both builtin opclasses/opfamilies as well as  
opclasses/opfamilies defined in extensions.  
  
Discussion: https://postgr.es/m/1529675324.14193.5.camel%40postgrespro.ru  
Author: Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov  
Reviewed-by: Michael Paquier, Alvaro Herrera, Arthur Zakirov  
Reviewed-by: Kyotaro Horiguchi, Andres Freund  

commit   : 691e8b2e1889d61df47ae76601fa9db6cbac6f1c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 7 Mar 2020 16:44:53 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 7 Mar 2020 16:44:53 -0800    

The data types that contrib/pageinspect's bt_metap() function were  
declared to return as OUT arguments were wrong in some cases.  For  
example, the oldest_xact column (a TransactionId/xid field) was declared  
integer/int4 within the pageinspect extension's sql file.  This led to  
errors when an oldest_xact value that exceeded 2^31-1 was encountered.  
Some of the other columns were defined incorrectly ever since  
pageinspect was first introduced, though they were far less likely to  
produce problems in practice.  
  
Fix these issues by changing the declaration of bt_metap() to  
consistently use data types that can reliably represent all possible  
values.  This fixes things on HEAD only.  No backpatch, since it doesn't  
seem like there is a safe way to fix the issue without including a new  
version of the pageinspect extension (HEAD/Postgres 13 already  
introduced a new version of the extension).  Besides, the oldest_xact  
issue has been around since the release of Postgres 11, and we haven't  
heard any complaints about it before now.  
  
Also, throw an error when we detect a bt_metap() declaration that must  
be from an old version of the pageinspect extension by examining the  
number of attributes from the tuple descriptor for the return tuples.  
It seems better to throw an error in a reliable and obvious way  
following a Postgres upgrade, rather than letting bt_metap() fail  
unpredictably.  The problem is fundamentally with the CREATE FUNCTION  
declared data types themselves, so I see no sensible alternative.  
  
Reported-By: Victor Yegorov  
Bug: #16285  
Discussion: https://postgr.es/m/16285-df8fc1000ab3d5fc@postgresql.org  

commit   : b9c3de62cbc9c6993ceac0de99985cf051e91c88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Mar 2020 16:58:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Mar 2020 16:58:07 -0500    

Jeff Janes, Georgios Kokolatos  
  
Discussion: https://postgr.es/m/CAMkU=1wU=vgxnvwy2HswLUVvoawrkrjZYeKXMr3w3p=_NNbGhQ@mail.gmail.com  

commit   : ea7dace2aa21e79a7a8eb23c493bcd2057d9bd7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Mar 2020 13:31:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Mar 2020 13:31:17 -0500    

I noticed while testing some other stuff that the CHECK_ENCODING_ROUNDTRIP  
logic in ginCompressPostingList could account for over 50% of the runtime  
of an INSERT with a GIN index.  While that's not relevant to production  
performance, it's still kind of annoying in a debug build.  Replacing  
the loop around short memcmp's with one long memcmp works just as well  
and is significantly faster, at least on my machine.  

commit   : 7e39b968f118c6444bd3a3bd59c3e9d73e652e0c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 14:04:09 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 14:04:09 +0100    

Some reference pages contained id attributes on refname elements.  
These were apparently copied around from ancient times, but they don't  
serve a purpose.  FOP issues minor warnings about them.  So it's  
easiest to just remove them.  

commit   : 33e27c3785c5ce8a3264d6af2550ec5adcebc517    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 10:57:03 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 10:57:03 +0100    

commit   : 8d7def5c27c18c85deaf4e55c39a074600f36b48    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 08:51:59 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Mar 2020 08:51:59 +0100    

commit   : 36058a3c55d2c42a513a53da8140b07cf0893afb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 17:11:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 17:11:23 -0500    

plperl's default handling of bool arguments or results is not terribly  
satisfactory, since Perl doesn't consider the string 'f' to be false.  
Ideally we'd just fix that, but the backwards-compatibility hazard  
would be substantial.  Instead, build a TRANSFORM module that can  
be optionally applied to provide saner semantics.  
  
Perhaps usefully, this is also about the minimum possible skeletal  
example of a plperl transform module; so it might be a better starting  
point for user-written transform modules than hstore_plperl or  
jsonb_plperl.  
  
Ivan Panchenko  
  
Discussion: https://postgr.es/m/1583013317.881182688@f390.i.mail.ru  

commit   : a6525588b7c21fd8539e9a43ec9c5c245ed1cc91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 14:17:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 14:17:43 -0500    

SQL includes provisions for numeric Unicode escapes in string  
literals and identifiers.  Previously we only accepted those  
if they represented ASCII characters or the server encoding  
was UTF-8, making the conversion to internal form trivial.  
This patch adjusts things so that we'll call the appropriate  
encoding conversion function in less-trivial cases, allowing  
the escape sequence to be accepted so long as it corresponds  
to some character available in the server encoding.  
  
This also applies to processing of Unicode escapes in JSONB.  
However, the old restriction still applies to client-side  
JSON processing, since that hasn't got access to the server's  
encoding conversion infrastructure.  
  
This patch includes some lexer infrastructure that simplifies  
throwing errors with error cursors pointing into the middle of  
a string (or other complex token).  For the moment I only used  
it for errors relating to Unicode escapes, but we might later  
expand the usage to some other cases.  
  
Patch by me, reviewed by John Naylor.  
  
Discussion: https://postgr.es/m/2393.1578958316@sss.pgh.pa.us  

commit   : fe30e7ebfa3846416f1adeb7cf611006513a4ee0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 12:19:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Mar 2020 12:19:29 -0500    

Specifically, this patch allows ALTER TYPE to:  
* Change the default TOAST strategy for a toastable base type;  
* Promote a non-toastable type to toastable;  
* Add/remove binary I/O functions for a type;  
* Add/remove typmod I/O functions for a type;  
* Add/remove a custom ANALYZE statistics functions for a type.  
  
The first of these can be done by the type's owner; all the others  
require superuser privilege since misuse could cause problems.  
  
The main motivation for this patch is to allow extensions to  
upgrade the feature sets of their data types, so the set of  
alterable properties is biased towards that use-case.  However  
it's also true that changing some other properties would be  
a lot harder, as they get baked into physical storage and/or  
stored expressions that depend on the type.  
  
Along the way, refactor GenerateTypeDependencies() to make it easier  
to call, refactor DefineType's volatility checks so they can be shared  
by AlterType, and teach typcache.c that it might have to reload data  
from the type's pg_type row, a scenario it never handled before.  
Also rearrange alter_type.sgml a bit for clarity (put the  
composite-type operations together).  
  
Tomas Vondra and Tom Lane  
  
Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development  

commit   : addd034ae1795d0a99305b294e4dce44c6b1dfd8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Mar 2020 08:15:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Mar 2020 08:15:29 +0900    

Issue introduced by me, as of 0065174.  
  
Reported-by: David Steele  
Discussion: https://postgr.es/m/1cf30561-7dad-dc6e-9fc3-5c456948cfeb@pgmasters.net  

commit   : bb03010b9f0766e10399174fe850b2506907c4e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:48:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:48:56 -0500    

A long time ago, it was necessary to declare datatype I/O functions,  
triggers, and language handler support functions in a very type-unsafe  
way involving a single pseudo-type "opaque".  We got rid of those  
conventions in 7.3, but there was still support in various places to  
automatically convert such functions to the modern declaration style,  
to be able to transparently re-load dumps from pre-7.3 servers.  
It seems unnecessary to continue to support that anymore, so take out  
the hacks; whereupon the "opaque" pseudo-type itself is no longer  
needed and can be dropped.  
  
This is part of a group of patches removing various server-side kluges  
for transparently upgrading pre-8.0 dump files.  Since we've had few  
complaints about dropping pg_dump's support for dumping from pre-8.0  
servers (commit 64f3524e2), it seems okay to now remove these kluges.  
  
Discussion: https://postgr.es/m/4110.1583255415@sss.pgh.pa.us  

commit   : 84eca14bc4bdf71911cceb3a6286bc47db3a5a06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:36:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:36:06 -0500    

Twenty years ago, we removed certain operator classes in favor of  
letting indexes over their data types be built with some other  
binary-compatible, more standard opclass.  As a hack to allow existing  
index definitions to be dumped and reloaded, we made CREATE INDEX ignore  
the removed opclass names, so that such indexes would fall back to the  
new default opclass for their data types.  This was never intended to  
be a long-lived thing; it carries the obvious risk of breaking some  
future developer's attempt to re-use those old opclass names.  Since  
all of the cases in question are for opclasses that were removed  
before PG 8.0, it seems okay to get rid of these hacks now.  
  
This is part of a group of patches removing various server-side kluges  
for transparently upgrading pre-8.0 dump files.  Since we've had few  
complaints about dropping pg_dump's support for dumping from pre-8.0  
servers (commit 64f3524e2), it seems okay to now remove these kluges.  
  
Discussion: https://postgr.es/m/3685.1583422389@sss.pgh.pa.us  

commit   : e58a5997528794687e40ec64b3c4d95a4e6cd0b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:25:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2020 15:25:45 -0500    

Before 7.3, foreign key constraints had no explicit catalog  
representation, so that what pg_dump produced for them was (usually)  
a set of three CREATE CONSTRAINT TRIGGER commands.  Commit a2899ebdc  
and some follow-on fixes added an ugly hack in CreateTrigger() to  
recognize that pattern and reconstruct the foreign key definition.  
However, we've never had any test coverage for that code, so that it's  
legitimate to wonder if it still works; and having to maintain it in  
the face of upcoming trigger-related patches seems rather pointless.  
Let's decree that its time has passed, and drop it.  
  
This is part of a group of patches removing various server-side kluges  
for transparently upgrading pre-8.0 dump files.  Since we've had few  
complaints about dropping pg_dump's support for dumping from pre-8.0  
servers (commit 64f3524e2), it seems okay to now remove these kluges.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/805874E2-999C-4CDA-856F-1AFBD9DFE933@yesql.se  

commit   : a77315fdf2a197a925e670be2d8b376c4ac02efc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Mar 2020 11:35:02 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Mar 2020 11:35:02 -0300    

We used to carry the I/O function OID in RangeIOData, but it's not used  
for anything.  Since the struct is not exposed to the world anyway, we  
can simplify it a bit.  Also, rename the FmgrInfo member to match  
the accompanying 'typioparam' and put them in a more sensible order.  
  
Reviewed by Tom Lane and Paul Jungwirth.  
  
Discussion: https://postgr.es/m/20200304215711.GA8732@alvherre.pgsql  

commit   : 0065174324a97c0f39ccf0823a81fb674fb49cca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2020 14:12:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2020 14:12:37 +0900    

This does not matter much when compiling Postgres proper as many  
warnings exist when enabling this compilation flag, but it can be  
annoying for external modules willing to use both.  
  
Author: David Steele  
Discussion: https://postgr.es/m/91d86c8a-11fc-7b88-43eb-5ca3f6fb8bd3@pgmasters.net  

commit   : 2eb3bc58814fa1ab86308a3658ddb76081080db3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2020 13:00:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2020 13:00:38 +0900    

This commit fixes the following two issues around .pgpass file.  
  
(1) If the length of a line in .pgpass file was larger than 319B,  
        libpq silently treated each 319B in the line as a separate  
        setting line.  
  
(2) The document explains that a line beginning with # is treated  
        as a comment in .pgpass. But there was no code doing such  
        special handling. Whether a line begins with # or not, libpq  
        just checked that the first token in the line match with the host.  
  
For (1), this commit makes libpq warn if the length of a line  
is larger than 319B, and throw away the remaining part beginning  
from 320B position.  
  
For (2), this commit changes libpq so that it treats any lines  
beginning with # as comments.  
  
Author: Fujii Masao  
Reviewed-by: Hamid Akhtar  
Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com  

commit   : fbcf0871123b464fef7f957301dcc57377cde9c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2020 12:50:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2020 12:50:15 +0900    

When canceling a REINDEX CONCURRENTLY operation after swapping is done,  
a drop of the parent table would leave behind old indexes.  This is a  
consequence of 68ac9cf, which fixed the case of pg_depend bloat when  
repeating REINDEX CONCURRENTLY on the same relation.  
  
In order to take care of the problem without breaking the previous fix,  
this uses a different strategy, possible even with the exiting set of  
routines to handle dependency changes.  The dependencies of/on the  
new index are additionally switched to the old one, allowing an old  
invalid index remaining around because of a cancellation or a failure to  
use the dependency links of the concurrently-created index.  This  
ensures that dropping any objects the old invalid index depends on also  
drops the old index automatically.  
  
Reported-by: Julien Rouhaud  
Author: Michael Paquier  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/20200227080735.l32fqcauy73lon7o@nol  
Backpatch-through: 12  

commit   : c954d49046504bde0a80b5fec53f4321dd88f1ea    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 4 Mar 2020 17:20:20 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 4 Mar 2020 17:20:20 -0800    

Optionally push a step to check for a NULL pointer to the pergroup  
state.  
  
This will be important for disk-based hash aggregation in combination  
with grouping sets. When memory limits are reached, a given tuple may  
find its per-group state for some grouping sets but not others. For  
the former, it advances the per-group state as normal; for the latter,  
it skips evaluation and the calling code will have to spill the tuple  
and reprocess it in a later batch.  
  
Add the NULL check as a separate expression step because in some  
common cases it's not needed.  
  
Discussion: https://postgr.es/m/20200221202212.ssb2qpmdgrnx52sj%40alap3.anarazel.de  

commit   : 3ed2005ff595d349276e5b2edeca1a8100b08c87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Mar 2020 10:34:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Mar 2020 10:34:25 -0500    

Our usual practice for "poor man's enum" catalog columns is to define  
macros for the possible values and use those, not literal constants,  
in C code.  But for some reason lost in the mists of time, this was  
never done for typalign/attalign or typstorage/attstorage.  It's never  
too late to make it better though, so let's do that.  
  
The reason I got interested in this right now is the need to duplicate  
some uses of the TYPSTORAGE constants in an upcoming ALTER TYPE patch.  
But in general, this sort of change aids greppability and readability,  
so it's a good idea even without any specific motivation.  
  
I may have missed a few places that could be converted, and it's even  
more likely that pending patches will re-introduce some hard-coded  
references.  But that's not fatal --- there's no expectation that  
we'd actually change any of these values.  We can clean up stragglers  
over time.  
  
Discussion: https://postgr.es/m/16457.1583189537@sss.pgh.pa.us  

commit   : 0ad6f848eef267489d4aee7306c16f96454b7a64    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Mar 2020 08:05:33 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Mar 2020 08:05:33 +0100    

This way we can make use of it in other components as well, and it  
fits better with the rest of the build system.  
  
Discussion: https://www.postgresql.org/message-id/flat/72fff73f-dc9c-4ef4-83e8-d2e60c98df48%402ndquadrant.com  

commit   : d67755049388526cd8673aa826dc794b97345eb3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Mar 2020 11:06:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Mar 2020 11:06:47 -0500    

to_char() has long allowed the TM (translation mode) prefix to  
specify output of translated month or day names; but that prefix  
had no effect in input format strings.  Now it does.  to_date()  
and to_timestamp() will now recognize the same month or day names  
that to_char() would output for the same format code.  Matching is  
case-insensitive (per the active collation's notion of what that  
means), just as it has always been for English month/day names  
without the TM prefix.  
  
(As per the discussion thread, there are lots of cases that this  
feature will not handle, such as alternate day names.  But being  
able to accept what to_char() will output seems useful enough.)  
  
In passing, fix some shaky English and violations of message  
style guidelines in jsonpath errors for the .datetime() method,  
which depends on this code.  
  
Juan José Santamaría Flecha, reviewed and modified by me,  
with other commentary from Alvaro Herrera, Tomas Vondra,  
Arthur Zakirov, Peter Eisentraut, Mark Dilger.  
  
Discussion: https://postgr.es/m/CAC+AXB3u1jTngJcoC1nAHBf=M3v-jrEfo86UFtCqCjzbWS9QhA@mail.gmail.com  

commit   : 1810ca18bfad9072facc548417630115b078483e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Feb 2020 16:33:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Feb 2020 16:33:05 +0100    

HAVE_WORKING_LINK is meant to indicate support for hard links, mainly  
for Windows.  Here it is used for soft links on Unix, and the  
functionality is optional anyway, so we can just make it error out  
normally if needed.  
  
Discussion: https://www.postgresql.org/message-id/flat/72fff73f-dc9c-4ef4-83e8-d2e60c98df48%402ndquadrant.com  

commit   : 61b73940452b1f6871a1d73f35216fb052a7a5ab    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 15:01:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 15:01:47 +0900    

Author: Noriyoshi Shinoda  

commit   : 1e07f5e0a1cf56f8cbc121dbb86c128a0f711c94    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 21:40:11 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 21:40:11 -0800    

_bt_split() is passed NULL as its insertion scankey for internal page  
splits.  Two recently added Assert() statements failed to consider this,  
leading to a crash with pg_upgrade'd BREE_VERSION < 4 indexes.  Remove  
the assertions.  
  
The assertions in question were added by commit 0d861bbb, which added  
nbtree deduplication.  It would be possible to fix the assertions  
directly instead, but they weren't adding much anyway.  

commit   : 0b48f1335dddb7141160e392cccac98edfb3fa85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Mar 2020 13:55:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Mar 2020 13:55:41 +0900    

Using ALTER TABLE ATTACH PARTITION causes an assertion failure when  
attempting to work on a partitioned index, because partitioned indexes  
cannot have partition bounds.  
  
The grammar of ALTER TABLE ATTACH PARTITION requires partition bounds,  
but not ALTER INDEX, so mixing ALTER TABLE with partitioned indexes is  
confusing.  Hence, on HEAD, prevent ALTER TABLE to attach a partition if  
the relation involved is a partitioned index.  On back-branches, as  
applications may rely on the existing behavior, just remove the  
culprit assertion.  
  
Reported-by: Alexander Lakhin  
Author: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/16276-5cd1dcc8fb8be7b5@postgresql.org  
Backpatch-through: 11  

commit   : 54a4f52a9258198243c53fceaf8da70546ebd652    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 12:22:04 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 12:22:04 +0900    

Previously the documentation explains that WAL segment files  
start at 000000010000000000000000. But the first WAL segment file  
that initdb creates is 000000010000000000000001 not  
000000010000000000000000. This change was caused by old  
commit 8c843fff2d, but the documentation had not been updated  
a long time.  
  
Back-patch to all supported branches.  
  
Author: Fujii Masao  
Reviewed-by: David Zhang  
Discussion: https://postgr.es/m/CAHGQGwHOmGe2OqGOmp8cOfNVDivq7dbV74L5nUGr+3eVd2CU2Q@mail.gmail.com  

commit   : e65497df8f85ab9b9084c928ff69f384ea729b24    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 12:03:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2020 12:03:43 +0900    

This commit adds pg_stat_progress_basebackup view that reports  
the progress while an application like pg_basebackup is taking  
a base backup. This uses the progress reporting infrastructure  
added by c16dc1aca5e0, adding support for streaming base backup.  
  
Bump catversion.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov  
Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com  

commit   : d79fb88ac738e0854e84a6c9445babfa5b2504b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Mar 2020 10:12:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Mar 2020 10:12:28 +0900    

If the flag value is lost, a CLUSTER query following REINDEX  
CONCURRENTLY could fail.  Non-concurrent REINDEX is already handling  
this case consistently.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200229024202.GH29456@telsasoft.com  
Backpatch-through: 12  

commit   : 91f3bd732cea7e25e53eaceae88232d0ab984434    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2020 18:41:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2020 18:41:50 -0500    

Thinko in 2f9661311.  Per buildfarm, as well as warning seen locally.  

commit   : 2f9661311b83dc481fc19f6e3bda015392010a40    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Mar 2020 18:19:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Mar 2020 18:19:51 -0300    

The backend was using strings to represent command tags and doing string  
comparisons in multiple places, but that's slow and unhelpful.  Create a  
new command list with a supporting structure to use instead; this is  
stored in a tag-list-file that can be tailored to specific purposes with  
a caller-definable C macro, similar to what we do for WAL resource  
managers.  The first first such uses are a new CommandTag enum and a  
CommandTagBehavior struct.  
  
Replace numerous occurrences of char *completionTag with a  
QueryCompletion struct so that the code no longer stores information  
about completed queries in a cstring.  Only at the last moment, in  
EndCommand(), does this get converted to a string.  
  
EventTriggerCacheItem no longer holds an array of palloc’d tag strings  
in sorted order, but rather just a Bitmapset over the CommandTags.  
  
Author: Mark Dilger, with unsolicited help from Álvaro Herrera  
Reviewed-by: John Naylor, Tom Lane  
Discussion: https://postgr.es/m/981A9DB4-3F0C-4DA5-88AD-CB9CFF4D6CAD@enterprisedb.com  

commit   : 7b425a5283cb2c8a452c2e79d6218e41373fd641    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2020 14:35:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2020 14:35:22 -0500    

Since commit 481c8e923 it tends to produce "error: sys/utime.h: No such  
file or directory" on non-Windows platforms.  

commit   : 90051cd8278bd089cf59ca6366df64de2982be2a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 10:29:30 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 10:29:30 -0800    

Add a cast to size_t to silence "comparison between signed and unsigned  
integer expressions" cpluspluscheck warning.  
  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/7971.1583171266@sss.pgh.pa.us  

commit   : 77b88bd5dc92a46319a3dd4b554f89f634bb9eaa    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 08:07:16 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 2 Mar 2020 08:07:16 -0800    

Copy some assertions from _bt_form_posting() to its sibling function,  
_bt_update_posting().  
  
Discussion: https://postgr.es/m/CAH2-WzkPR8KMwkL0ap976kmXwBCeukTeHz6fB-U__wvuP1S9Zg@mail.gmail.com  

commit   : ed0d8837658946de4c965a55bf0ea73fd2682d7f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Mar 2020 15:21:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Mar 2020 15:21:42 +0100    

Reported-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAC%2BAXB1EDXiRPmiVfh%2BWX79x5vXJDU17k0GkDjfyPgOWO4Y5og%40mail.gmail.com  

commit   : d433b79b89c7d429ab69cb00857a8aca45d0ad47    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Mar 2020 08:55:31 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Mar 2020 08:55:31 +0100    

Author: Vignesh C <vignesh21@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CALDaNm3sn4yOq-4rogb-CfE0EYw6b3mVzz8+DnS9BNRwPnhngw@mail.gmail.com  

commit   : 3b77dce863d94de2de40b2a302c0f58248655e6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2020 15:45:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2020 15:45:34 +0900    

When setting PG_COLOR to "always" or "auto" in a Windows terminal  
VT100-compatible, the colorization output was not showing up correctly  
because it is necessary to update the console's output handling mode.  
This fix allows to detect automatically if the environment is compatible  
with VT100.  Hence, PG_COLOR=auto is able to detect and handle both  
compatible and non-compatible environments.  The behavior of  
PG_COLOR=always remains unchanged, as it enforces the use of colorized  
output even if the environment does not allow it.  
  
This fix is based on an initial suggestion from Thomas Munro.  
  
Reported-by: Haiying Tang  
Author: Juan José Santamaría Flecha  
Reviewed-by: Michail Nikolaev, Michael Paquier, Haiying Tang  
Discussion: https://postgr.es/m/16108-134692e97146b7bc@postgresql.org  
Backpatch-through: 12  

commit   : 12c5cad76f9247f39b6e542ef1c6255912c2adda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2020 10:00:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2020 10:00:37 +0900    

The code path for multi-insert decoding is not stressed yet for  
catalogs (a future patch may introduce this capability), so no  
back-patch is needed.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/9690D72F-5C4F-4016-9572-6D16684E1D87@yesql.se  

commit   : 84ec9b231a865348f5388dcc125c084297709332    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 1 Mar 2020 12:11:26 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 1 Mar 2020 12:11:26 -0800    

Discussion: https://postgr.es/m/CAH2-WzmAufHiOku6AGiFD=81VQs5nYJ1L2YkhW1t+BH4CMsgRw@mail.gmail.com  

commit   : 43a899f41f46918a0bf442edb091b08c214c68f8    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 1 Mar 2020 14:49:25 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 1 Mar 2020 14:49:25 +0000    

When deciding on the local rscale to use for the Taylor series  
expansion, ln_var() neglected to account for the fact that the result  
is subsequently multiplied by a factor of 2^(nsqrt+1), where nsqrt is  
the number of square root operations performed in the range reduction  
step, which can be as high as 22 for very large inputs. This could  
result in a loss of precision, particularly when combined with large  
rscale values, for which a large number of Taylor series terms is  
required (up to around 400).  
  
Fix by computing a few extra digits in the Taylor series, based on the  
weight of the multiplicative factor log10(2^(nsqrt+1)). It remains to  
be proven whether or not the other 8 extra digits used for the Taylor  
series is appropriate, but this at least deals with the obvious  
oversight of failing to account for the effects of the final  
multiplication.  
  
Per report from Justin AnyhowStep. Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/16280-279f299d9c06e56f@postgresql.org  

commit   : dba915333967609cc7ca73f0904dfdc08db0a052    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 29 Feb 2020 15:10:13 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 29 Feb 2020 15:10:13 -0800    

Oversight in commit 93ee38ea.  

commit   : 93ee38eade1b2b4964354b95b01b09e17d6f098d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 29 Feb 2020 12:10:17 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 29 Feb 2020 12:10:17 -0800    

Add a new bt_metap() column to display the metapage's allequalimage  
field.  Also add three new columns to contrib/pageinspect's  
bt_page_items() function:  
  
* Add a boolean column ("dead") that displays the LP_DEAD bit value for  
each non-pivot tuple.  
  
* Add a TID column ("htid") that displays a single heap TID value for  
each tuple.  This is the TID that is returned by BTreeTupleGetHeapTID(),  
so comparable values are shown for pivot tuples, plain non-pivot tuples,  
and posting list tuples.  
  
* Add a TID array column ("tids") that displays TIDs from each tuple's  
posting list, if any.  This works just like the "tids" column from  
pageinspect's gin_leafpage_items() function.  
  
No version bump for the pageinspect extension, since there hasn't been a  
stable Postgres release since the last version bump (the last bump was  
part of commit 58b4cb30).  
  
Author: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzmSMmU2eNvY9+a4MNP+z02h6sa-uxZvN3un6jY02ZVBSw@mail.gmail.com  

commit   : 58c47ccfff20b8c125903482725c1dbfd30beade    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Feb 2020 13:48:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Feb 2020 13:48:09 -0500    

Commit 356687bd8 omitted to remove leftover code for destroying  
a hashed subplan's hash tables, with the result that the tables  
were always rebuilt not reused; this leads to severe memory  
leakage if a hashed subplan is re-executed enough times.  
Moreover, the code for reusing the hashnulls table had a typo  
that would have made it do the wrong thing if it were reached.  
  
Looking at the code coverage report shows severe under-coverage  
of the potential callers of ResetTupleHashTable, so add some test  
cases that exercise them.  
  
Andreas Karlsson and Tom Lane, per reports from Ranier Vilela  
and Justin Pryzby.  
  
Backpatch to v11, as the faulty commit was.  
  
Discussion: https://postgr.es/m/edb62547-c453-c35b-3ed6-a069e4d6b937@proxel.se  
Discussion: https://postgr.es/m/CAEudQAo=DCebm1RXtig9OH+QivpS97sMkikt0A9qHmMUs+g6ZA@mail.gmail.com  
Discussion: https://postgr.es/m/20200210032547.GA1412@telsasoft.com  

commit   : 6afc8aefd3b95c0c4e7d07d2c99b90ce83e313de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Feb 2020 13:23:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Feb 2020 13:23:12 -0500    

Noted while studying subplan hash issue.  

commit   : 80d76be51cfb7f8f54e779ec5a287d80ac28b6e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Feb 2020 20:28:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Feb 2020 20:28:34 -0500    

Such an access became possible when commit 246a6c8f7 added more  
aggressive cleanup of orphaned temp relations by autovacuum.  
Since autovacuum's snapshot might be slightly stale, it could  
attempt to access an already-dropped temp namespace, resulting in  
an assertion failure or null-pointer dereference.  (In practice,  
since we don't drop temp namespaces automatically but merely  
recycle them, this situation could only arise if a superuser does  
a manual drop of a temp namespace.  Still, that should be allowed.)  
  
The core of the bug, IMO, is that isTempNamespaceInUse and its callers  
failed to think hard about whether to treat "temp namespace isn't there"  
differently from "temp namespace isn't in use".  In hopes of forestalling  
future mistakes of the same ilk, replace that function with a new one  
checkTempNamespaceStatus, which makes the same tests but returns a  
three-way enum rather than just a bool.  isTempNamespaceInUse is gone  
entirely in HEAD; but just in case some external code is relying on it,  
keep it in the back branches, as a bug-compatible wrapper around the  
new function.  
  
Per report originally from Prabhat Kumar Sahu, investigated by Mahendra  
Singh and Michael Paquier; the final form of the patch is my fault.  
This replaces the failed fix attempt in a052f6cbb.  
  
Backpatch as far as v11, as 246a6c8f7 was.  
  
Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com  

commit   : 32bb4535a0be892f4a2794a26ba429032f4ae51e    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 28 Feb 2020 09:32:35 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 28 Feb 2020 09:32:35 -0800    

I neglected to update copyfuncs/outfuncs/readfuncs.  
  
Discussion: https://postgr.es/m/12491.1582833409%40sss.pgh.pa.us  

commit   : 963ea55c34cc325243fd30468ce8c629572f0c73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Feb 2020 11:29:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Feb 2020 11:29:58 -0500    

Access to this module is granted to the pg_monitor role, not  
pg_read_all_stats.  (Given the view's performance impact,  
it seems wise to be restrictive, so I think this was the  
correct decision --- and anyway it was clearly intentional.)  
  
Per bug #16279 from Philip Semanchuk.  
  
Discussion: https://postgr.es/m/16279-fcaac33c68aab0ab@postgresql.org  

commit   : db989184cda7f4aa1ff764cca96142029e7e093b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Feb 2020 13:13:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Feb 2020 13:13:54 -0300    

Apparently, reusing the parse-time query snapshot for later steps  
(execution) is a frequently considered optimization ... but it doesn't  
work, for reasons discovered in thread [1].  Adding some comments about  
why it doesn't really work can relieve some future hackers from wasting  
time reimplementing it again.  
  
[1] https://postgr.es/m/flat/5075D8DF.6050500@fuzzy.cz  
  
Author: Michail Nikolaev  
Discussion: https://postgr.es/m/CANtu0ogp6cTvMJObXP8n=k+JtqxY1iT9UV5MbGCpjjPa5crCiw@mail.gmail.com  

commit   : 1933ae629e7b706c6c23673a381e778819db307d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 28 Feb 2020 08:54:49 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 28 Feb 2020 08:54:49 +0100    

Per emerging standard in GNU programs and elsewhere.  Autoconf already  
has support for specifying a home page, so we can just that.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com  

commit   : 864934131ef72dc3a403ad1375a94543fcc04206    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 28 Feb 2020 08:54:49 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 28 Feb 2020 08:54:49 +0100    

Use the PACKAGE_BUGREPORT macro that is created by Autoconf for  
referring to the bug reporting address rather than hardcoding it  
everywhere.  This makes it easier to change the address and it reduces  
translation work.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com  

commit   : afb5465e0cfce7637066eaaaeecab30b0f23fbe3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2020 17:25:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2020 17:25:47 -0300    

Per Tom Lane.  

commit   : c11cb17dc55a6b432dc637491a4491920f9c2770    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 27 Feb 2020 10:46:58 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 27 Feb 2020 10:46:58 -0800    

This will be useful in the upcoming Hash Aggregation work to improve  
estimates for hash table sizing.  
  
Discussion: https://postgr.es/m/37091115219dd522fd9ed67333ee8ed1b7e09443.camel%40j-davis.com  

commit   : e537aed61db767745b614600be15cd19bb581330    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 Feb 2020 09:32:34 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 Feb 2020 09:32:34 -0800    

Reported-By: Fujii Masao  
Discussion: https://postgr.es/m/18f07ae8-7d89-537c-b0a9-54100a1b46da@oss.nttdata.com  

commit   : b9b408c487244ef8e6d613d183c56eb2c62990b1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2020 13:23:33 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2020 13:23:33 -0300    

This let us get rid of a recently introduced ugly hack (commit  
1fa846f1c9af).  
  
Author: Álvaro Herrera  
Reviewed-by: Amit Langote, Tom Lane  
Discussion: https://postgr.es/m/20200217215641.GA29784@alvherre.pgsql  

commit   : c4b0edb07ed53063ea4c86cd7918ad6ea01d8979    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 21:58:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 21:58:37 +0900    

OpenBSD falls back to "C" when using an incorrect input with setlocale()  
and LC_CTYPE, causing this test, introduced by 008cf04, to fail.  This  
removes the culprit test to avoid the portability issue.  
  
Per report from Robert Haas, via buildfarm member curculio.  
  
Discussion: https://postgr.es/m/CA+TgmoZ6ddh3mHD9gU8DvNYoFmuJaYYn1+4AvZNp25vTdRwCAQ@mail.gmail.com  
Backpatch-through: 11  

commit   : 428a2609ef64b69d709418a50e192ff11a2643f1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 15:31:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 15:31:27 +0900    

Attempting to use pg_checksums (pg_verify_checksums in 11) on a data  
folder which includes tablespace paths used across multiple major  
versions would cause pg_checksums to scan all directories present in  
pg_tblspc, and not only marked with TABLESPACE_VERSION_DIRECTORY.  This  
could lead to failures when for example running sanity checks on an  
upgraded instance with --check.  Even worse, it was possible to rewrite  
on-disk pages with --enable for a cluster potentially online.  
  
This commit makes pg_checksums skip any directories not named  
TABLESPACE_VERSION_DIRECTORY, similarly to what is done for base  
backups.  
  
Reported-by: Michael Banck  
Author: Michael Banck, Bernd Helmle  
Discussion: https://postgr.es/m/62031974fd8e941dd8351fbc8c7eff60d59c5338.camel@credativ.de  
backpatch-through: 11  

commit   : 05d8449e73694585b59f8b03aaa087f04cc4679a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Feb 2020 09:25:41 +0530    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Feb 2020 09:25:41 +0530    

This also involves renaming src/include/utils/hashutils.h, which  
becomes src/include/common/hashfn.h. Perhaps an argument can be  
made for keeping the hashutils.h name, but it seemed more  
consistent to make it match the name of the file, and also more  
descriptive of what is actually going on here.  
  
Patch by me, reviewed by Suraj Kharage and Mark Dilger. Off-list  
advice on how not to break the Windows build from Davinder Singh  
and Amit Kapila.  
  
Discussion: http://postgr.es/m/CA+TgmoaRiG4TXND8QuM6JXFRkM_1wL2ZNhzaUKsuec9-4yrkgw@mail.gmail.com  

commit   : 008cf040962c98c7c55d54c28dcb43c3c1d83c92    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 11:20:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2020 11:20:46 +0900    

The original coding failed to properly quote those arguments, leading to  
failures when using quotes in the values used.  As the quoting can be  
encoding-sensitive, the connection to the backend needs to be taken  
before applying the correct quoting.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200214041004.GB1998@paquier.xyz  
Backpatch-through: 9.5  

commit   : 2c0797da2c26dd5574e0d9128887c1fc2a385c25    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 15:15:45 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 15:15:45 -0800    

Per complaint from Álvaro Herrera.  

commit   : a477bfc1dfb8d2b7125a9818edcbf383bf82d62a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Feb 2020 18:13:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Feb 2020 18:13:58 -0500    

eval_const_expressions sometimes produced RelabelType nodes that  
were useless because they just relabeled an expression to the same  
exposed type it already had.  This is worth avoiding because it can  
cause two equivalent expressions to not be equal(), preventing  
recognition of useful optimizations.  In the test case added here,  
an unpatched planner fails to notice that the "sqli = constant" clause  
renders a sort step unnecessary, because one code path produces an  
extra RelabelType and another doesn't.  
  
Fix by ensuring that eval_const_expressions_mutator's T_RelabelType  
case will not add in an unnecessary RelabelType.  Also save some  
code by sharing a subroutine with the effectively-equivalent cases  
for CollateExpr and CoerceToDomain.  (CollateExpr had no bug, and  
I think that the case couldn't arise with CoerceToDomain, but  
it seems prudent to do the same check for all three cases.)  
  
Back-patch to v12.  In principle this has been wrong all along,  
but I haven't seen a case where it causes visible misbehavior  
before v12, so refrain from changing stable branches unnecessarily.  
  
Per investigation of a report from Eric Gillum.  
  
Discussion: https://postgr.es/m/CAMmjdmvAZsUEskHYj=KT9sTukVVCiCSoe_PBKOXsncFeAUDPCQ@mail.gmail.com  

commit   : 3acfe6b089a5283c2961eb2ff135106e23b89263    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Feb 2020 19:57:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Feb 2020 19:57:14 -0300    

In commit 86f575948c77 I forgot to update the trigger.sgml paragraph  
that needs to explain that AFTER triggers are allowed in partitioned  
tables.  Do so now.  
  
Discussion: https://postgr.es/m/20200224185850.GA30899@alvherre.pgsql  

commit   : 2d8a6fad18fcec1850b79ddcf3a0032058d86715    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 13:17:36 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 13:17:36 -0800    

Per buildfarm member longfin.  

commit   : 0d861bbb702f8aa05c2a4e3f1650e7e8df8c8c27    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 13:05:30 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 13:05:30 -0800    

Deduplication reduces the storage overhead of duplicates in indexes that  
use the standard nbtree index access method.  The deduplication process  
is applied lazily, after the point where opportunistic deletion of  
LP_DEAD-marked index tuples occurs.  Deduplication is only applied at  
the point where a leaf page split would otherwise be required.  New  
posting list tuples are formed by merging together existing duplicate  
tuples.  The physical representation of the items on an nbtree leaf page  
is made more space efficient by deduplication, but the logical contents  
of the page are not changed.  Even unique indexes make use of  
deduplication as a way of controlling bloat from duplicates whose TIDs  
point to different versions of the same logical table row.  
  
The lazy approach taken by nbtree has significant advantages over a GIN  
style eager approach.  Most individual inserts of index tuples have  
exactly the same overhead as before.  The extra overhead of  
deduplication is amortized across insertions, just like the overhead of  
page splits.  The key space of indexes works in the same way as it has  
since commit dd299df8 (the commit that made heap TID a tiebreaker  
column).  
  
Testing has shown that nbtree deduplication can generally make indexes  
with about 10 or 15 tuples for each distinct key value about 2.5X - 4X  
smaller, even with single column integer indexes (e.g., an index on a  
referencing column that accompanies a foreign key).  The final size of  
single column nbtree indexes comes close to the final size of a similar  
contrib/btree_gin index, at least in cases where GIN's posting list  
compression isn't very effective.  This can significantly improve  
transaction throughput, and significantly reduce the cost of vacuuming  
indexes.  
  
A new index storage parameter (deduplicate_items) controls the use of  
deduplication.  The default setting is 'on', so all new B-Tree indexes  
automatically use deduplication where possible.  This decision will be  
reviewed at the end of the Postgres 13 beta period.  
  
There is a regression of approximately 2% of transaction throughput with  
synthetic workloads that consist of append-only inserts into a table  
with several non-unique indexes, where all indexes have few or no  
repeated values.  The underlying issue is that cycles are wasted on  
unsuccessful attempts at deduplicating items in non-unique indexes.  
There doesn't seem to be a way around it short of disabling  
deduplication entirely.  Note that deduplication of items in unique  
indexes is fairly well targeted in general, which avoids the problem  
there (we can use a special heuristic to trigger deduplication passes in  
unique indexes, since we're specifically targeting "version bloat").  
  
Bump XLOG_PAGE_MAGIC because xl_btree_vacuum changed.  
  
No bump in BTREE_VERSION, since the representation of posting list  
tuples works in a way that's backwards compatible with version 4 indexes  
(i.e. indexes built on PostgreSQL 12).  However, users must still  
REINDEX a pg_upgrade'd index to use deduplication, regardless of the  
Postgres version they've upgraded from.  This is the only way to set the  
new nbtree metapage flag indicating that deduplication is generally  
safe.  
  
Author: Anastasia Lubennikova, Peter Geoghegan  
Reviewed-By: Peter Geoghegan, Heikki Linnakangas  
Discussion:  
    https://postgr.es/m/55E4051B.7020209@postgrespro.ru  
    https://postgr.es/m/4ab6e2db-bcee-f4cf-0916-3a06e6ccbb55@postgrespro.ru  

commit   : 612a1ab76724aa1514b6509269342649f8cab375    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 11:28:25 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Feb 2020 11:28:25 -0800    

Invent the concept of a B-Tree equalimage ("equality implies image  
equality") support function, registered as support function 4.  This  
indicates whether it is safe (or not safe) to apply optimizations that  
assume that any two datums considered equal by an operator class's order  
method must be interchangeable without any loss of semantic information.  
This is static information about an operator class and a collation.  
  
Register an equalimage routine for almost all of the existing B-Tree  
opclasses.  We only need two trivial routines for all of the opclasses  
that are included with the core distribution.  There is one routine for  
opclasses that index non-collatable types (which returns 'true'  
unconditionally), plus another routine for collatable types (which  
returns 'true' when the collation is a deterministic collation).  
  
This patch is infrastructure for an upcoming patch that adds B-Tree  
deduplication.  
  
Author: Peter Geoghegan, Anastasia Lubennikova  
Discussion: https://postgr.es/m/CAH2-Wzn3Ee49Gmxb7V1VJ3-AC8fWn-Fr8pfWQebHe8rYRxt5OQ@mail.gmail.com  

commit   : 4109bb5de4998b9301ea2ac18c9d6dfb0b4f900b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 26 Feb 2020 10:03:11 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 26 Feb 2020 10:03:11 +0100    

In passing, also quote the filename in one message where it wasn't.  
  
Author: Dagfinn Ilmari Mannsåker  
Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org  

commit   : 59f9cd9dd5e4db8c59c57a17388c17564a3211a3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Feb 2020 13:57:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Feb 2020 13:57:40 +0900    

GenerateConfigHeader() in Solution.pm was complaining about unused  
define symbols even if a newer config header was not generated, causing  
successive build attempts with MSVC to fail.  
  
Oversight in commit 8f4fb4c.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/20200218.160500.44393633318853097.horikyota.ntt@gmail.com  

commit   : 36390713a60f446da7e7ae758771c9104fa89394    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Feb 2020 18:43:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Feb 2020 18:43:23 -0500    

I forgot that some compilers won't handle #if constructs within  
ereport() calls.  Duplicating most of the call is annoying but simple.  
Per buildfarm.  

commit   : 2742c45080077ed3b08b810bb96341499b86d530    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Feb 2020 14:39:22 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Feb 2020 14:39:22 -0800    

Do so by combining the various steps that are part of aggregate  
transition function invocation into one larger step. As some of the  
current steps are only necessary for some aggregates, have one variant  
of the aggregate transition step for each possible combination.  
  
To avoid further manual copies of code in the different transition  
step implementations, move most of the code into helper functions  
marked as "always inline".  
  
The benefit of this change is an increase in performance when  
aggregating lots of rows. This comes in part due to the reduced number  
of indirect jumps due to the reduced number of steps, and in part by  
reducing redundant setup code across steps. This mainly benefits  
interpreted execution, but the code generated by JIT is also improved  
a bit.  
  
As a nice side-effect it also ends up making the code a bit simpler.  
  
A small additional optimization is removing the need to set  
aggstate->curaggcontext before calling ExecAggInitGroup, choosing to  
instead passign curaggcontext as an argument. It was, in contrast to  
other aggregate related functions, only needed to fetch a memory  
context to copy the transition value into.  
  
Author: Andres Freund  
Discussion:  
   https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de  
   https://postgr.es/m/5c371df7cee903e8cd4c685f90c6c72086d3a2dc.camel@j-davis.com  

commit   : 7d672b76bf27327dc3527dabcd8be4e2dedf430f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Feb 2020 07:55:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Feb 2020 07:55:22 +0900    

Multi-insert for heap is not yet used actively for catalogs, but the  
code to support this case is in place for logical decoding.  The  
existing code forgot to issue a XLOG_HEAP2_NEW_CID record for the first  
tuple inserted, leading to failures when attempting to use multiple  
inserts for catalogs at decoding time.  This commit fixes the problem by  
WAL-logging the needed CID.  
  
This is not an active bug, so no back-patch is done.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/E0D4CC67-A1CF-4DF4-991D-B3AC2EB5FAE9@yesql.se  

commit   : 3d475515a15f70a4a3f36fbbba93db6877ff8346    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Feb 2020 17:28:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Feb 2020 17:28:33 -0500    

The comments in fd.c have long claimed that all file allocations should  
go through that module, but in reality that's not always practical.  
fd.c doesn't supply APIs for invoking some FD-producing syscalls like  
pipe() or epoll_create(); and the APIs it does supply for non-virtual  
FDs are mostly insistent on releasing those FDs at transaction end;  
and in some cases the actual open() call is in code that can't be made  
to use fd.c, such as libpq.  
  
This has led to a situation where, in a modern server, there are likely  
to be seven or so long-lived FDs per backend process that are not known  
to fd.c.  Since NUM_RESERVED_FDS is only 10, that meant we had *very*  
few spare FDs if max_files_per_process is >= the system ulimit and  
fd.c had opened all the files it thought it safely could.  The  
contrib/postgres_fdw regression test, in particular, could easily be  
made to fall over by running it under a restrictive ulimit.  
  
To improve matters, invent functions Acquire/Reserve/ReleaseExternalFD  
that allow outside callers to tell fd.c that they have or want to allocate  
a FD that's not directly managed by fd.c.  Add calls to track all the  
fixed FDs in a standard backend session, so that we are honestly  
guaranteeing that NUM_RESERVED_FDS FDs remain unused below the EMFILE  
limit in a backend's idle state.  The coding rules for these functions say  
that there's no need to call them in code that just allocates one FD over  
a fairly short interval; we can dip into NUM_RESERVED_FDS for such cases.  
That means that there aren't all that many places where we need to worry.  
But postgres_fdw and dblink must use this facility to account for  
long-lived FDs consumed by libpq connections.  There may be other places  
where it's worth doing such accounting, too, but this seems like enough  
to solve the immediate problem.  
  
Internally to fd.c, "external" FDs are limited to max_safe_fds/3 FDs.  
(Callers can choose to ignore this limit, but of course it's unwise  
to do so except for fixed file allocations.)  I also reduced the limit  
on "allocated" files to max_safe_fds/3 FDs (it had been max_safe_fds/2).  
Conceivably a smarter rule could be used here --- but in practice,  
on reasonable systems, max_safe_fds should be large enough that this  
isn't much of an issue, so KISS for now.  To avoid possible regression  
in the number of external or allocated files that can be opened,  
increase FD_MINFREE and the lower limit on max_files_per_process a  
little bit; we now insist that the effective "ulimit -n" be at least 64.  
  
This seems like pretty clearly a bug fix, but in view of the lack of  
field complaints, I'll refrain from risking a back-patch.  
  
Discussion: https://postgr.es/m/E1izCmM-0005pV-Co@gemulon.postgresql.org  

commit   : 1420617b14e2e3722367b826986a50ea33ff62ec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Feb 2020 16:32:34 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Feb 2020 16:32:34 +0100    

Given all we have learned about fsync() error handling in the last few  
years, reporting an fsync() error non-fatally is not useful,  
unless you don't care much about the file, in which case you probably  
don't need to use fsync() in the first place.  
  
Change fsync_fname() and durable_rename() to exit(1) on fsync() errors  
other than those that we specifically chose to ignore.  
  
This affects initdb, pg_basebackup, pg_checksums, pg_dump, pg_dumpall,  
and pg_rewind.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/d239d1bd-aef0-ca7c-dc0a-da14bdcf0392%402ndquadrant.com  

commit   : a91e2fa94180f24dd68fb6c99136cda820e02089    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:27:15 +0530    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:27:15 +0530    

hash_any() and its various variants are defined to return Datum,  
which is a backend-only concept, but the underlying functions  
actually want to return uint32 and uint64, and only return Datum  
because it's convenient for callers who are using them to  
implement a hash function for some SQL datatype.  
  
However, changing these functions to return uint32 and uint64  
seems like it might lead to programming errors or back-patching  
difficulties, both because they are widely used and because  
failure to use UInt{32,64}GetDatum() might not provoke a  
compilation error. Instead, rename the existing functions as  
well as changing the return type, and add static inline wrappers  
for those callers that need the previous behavior.  
  
Although this commit adapts hashutils.h and hashfn.c so that they  
can be compiled as frontend code, it does not actually do  
anything that would cause them to be so compiled. That is left  
for another commit.  
  
Patch by me, reviewed by Suraj Kharage and Mark Dilger.  
  
Discussion: http://postgr.es/m/CA+TgmoaRiG4TXND8QuM6JXFRkM_1wL2ZNhzaUKsuec9-4yrkgw@mail.gmail.com  

commit   : 9341c783cc42ffae5860c86bdc713bd47d734ffd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:22:45 +0530    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:22:45 +0530    

Previously, some of the prototypes for functions in hashfn.c were  
in utils/hashutils.h and others were in utils/hsearch.h, but that  
is confusing and has no particular benefit.  
  
Patch by me, reviewed by Suraj Kharage and Mark Dilger.  
  
Discussion: http://postgr.es/m/CA+TgmoaRiG4TXND8QuM6JXFRkM_1wL2ZNhzaUKsuec9-4yrkgw@mail.gmail.com  

commit   : 07b95c3d8334f737d4717c91967729f7721e785c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:17:08 +0530    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Feb 2020 17:17:08 +0530    

The closely-related function bms_hash_value is already defined in that  
file, and this change means that hashfn.c no longer needs to depend on  
nodes/bitmapset.h. That gets us closer to allowing use of the hash  
functions in hashfn.c in frontend code.  
  
Patch by me, reviewed by Suraj Kharage and Mark Dilger.  
  
Discussion: http://postgr.es/m/CA+TgmoaRiG4TXND8QuM6JXFRkM_1wL2ZNhzaUKsuec9-4yrkgw@mail.gmail.com  

commit   : bf883b211eae18662f2dfaede02f5d115bf0b805    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 24 Feb 2020 18:13:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 24 Feb 2020 18:13:25 +0900    

An instance of PostgreSQL crashing with a bad timing could leave behind  
temporary pg_internal.init files, potentially causing failures when  
verifying checksums.  As the same exclusion lists are used between  
pg_rewind, pg_checksums and basebackup.c, all those tools are extended  
with prefix checks to keep everything in sync, with dedicated checks  
added for pg_internal.init.  
  
Backpatch down to 11, where pg_checksums (pg_verify_checksums in 11) and  
checksum verification for base backups have been introduced.  
  
Reported-by: Michael Banck  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, David Steele  
Discussion: https://postgr.es/m/62031974fd8e941dd8351fbc8c7eff60d59c5338.camel@credativ.de  
Backpatch-through: 11  

commit   : 79c2385915dd4aa43127e766c3dce323ec562ba0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:58:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:58:02 +0100    

Right now this only makes BootStrapXLOG() a bit more manageable, but  
in the future there may be external callers.  
  
Discussion: https://www.postgresql.org/message-id/e8f86ba5-48f1-a80a-7f1d-b76bcb9c5c47@2ndquadrant.com  

commit   : 9745f93afc56829f9cf10ca3e43a29f0b4409fe3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:46:37 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:46:37 +0100    

Discussion: https://www.postgresql.org/message-id/e8f86ba5-48f1-a80a-7f1d-b76bcb9c5c47@2ndquadrant.com  

commit   : 5f1b8260af961ddf05968c9c3e7f178a3ad5d2ea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:35:48 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 17:35:48 +0100    

ReadControlFile() here conflicts with a function of the same name in  
xlog.c.  There is no actual conflict right now, but since  
pg_resetwal.c reaches deep inside backend headers, it's possible in  
the future.  
  
Discussion: https://www.postgresql.org/message-id/e8f86ba5-48f1-a80a-7f1d-b76bcb9c5c47@2ndquadrant.com  

commit   : ec4a7851d5914bbdc5b65175e2489ec19020217e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 16:14:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 16:14:09 -0500    

We're not testing that anywhere anymore, but for consistency,  
it should get defined.  

commit   : b24e125696a94b6ebdd2262c0c41bf45cbeba23f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 22:03:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 22:03:05 +0100    

commit   : 73c8596488fd5fd619991f56dae5d22f551b06d9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 20:50:56 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 20:50:56 +0100    

This to allow verifying the MSVC build file generation without having  
to have Windows.  
  
To do this, we avoid Windows-specific Perl modules and don't run the  
"cl" compiler or "nmake".  The resulting build files won't actually be  
completely correct, but it's useful enough.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/d73b2c7b-f081-8357-8422-7564d55f1aac%402ndquadrant.com  

commit   : f4d59369d2ddf0ad7850112752ec42fd115825d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:30:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:30:21 -0500    

These compiler features are required by C99, so remove the configure  
probes for them.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 97cf1fa4ed57cc1ed556ac4f827e7df8538f2d29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:11:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:11:39 -0500    

Windows has this, and so do all other live platforms according to the  
buildfarm; it's been required by POSIX since SUSv2.  So remove the  
configure probe and tests of HAVE_WCHAR_H.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 481c8e9232386e289fbd3e8f75893ae8d9814298    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:04:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 14:04:19 -0500    

These are required by POSIX since SUSv2, and no live platforms fail  
to provide them.  On Windows, utime() exists and we bring our own  
<utime.h>, so we're good there too.  So remove the configure probes  
and ad-hoc substitute code.  We don't need to check for utimes()  
anymore either, since that was only used as a substitute.  
  
In passing, make the Windows build include <sys/utime.h> only where  
we need it, not everywhere.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : f88a058200a40032e88a8bfc1aea453c22d2dcb0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:47:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:47:40 -0500    

Windows has this since _MSC_VER >= 1200, and so do all other live  
platforms according to the buildfarm, so remove the configure probe  
and src/port/ substitution.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 1200d71a09177b7e64167df440d0c9bd16111ebe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:42:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:42:28 -0500    

Windows has this, and so do all other live platforms according to the  
buildfarm, so remove the configure probe and c.h's substitute code.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : abe41f453a5c42129e21825d75450aced0053eb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:24:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:24:21 -0500    

Windows has this, and so do all other live platforms according to the  
buildfarm, so remove the configure probe and float.c's substitute code.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 7fde892bc191e4df9fcd52ce11d1502673498d97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:18:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 13:18:27 -0500    

Windows has this, and so do all other live platforms according to the  
buildfarm, so remove the configure probe and src/port/ substitution.  
  
This also lets us get rid of some configure probes that existed only  
to support src/port/isinf.c.  I kept the port.h hack to force using  
__builtin_isinf() on clang, though.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 799d22461a932aace890d61a82186e0d64de0ee8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 12:49:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2020 12:49:42 -0500    

Windows has this, and so do all other live platforms according to the  
buildfarm, so remove the configure probe and src/port/ substitution.  
  
Keep the probe that detects whether _LARGEFILE_SOURCE has to be  
defined to get that, though ... that seems to be still relevant in  
some places.  
  
This is part of a series of commits to get rid of no-longer-relevant  
configure checks and dead src/port/ code.  I'm committing them separately  
to make it easier to back out individual changes if they prove less  
portable than I expect.  
  
Discussion: https://postgr.es/m/15379.1582221614@sss.pgh.pa.us  

commit   : 3f9c1697dca0b4964f1f5ba624d361d4e0e53051    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 19:49:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 19:49:44 +0100    

GCC reports various instances of  
  
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]  
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]  
  
and MSVC equivalently  
  
warning C4312: 'type cast': conversion from 'int' to 'void *' of greater size  
warning C4311: 'type cast': pointer truncation from 'void *' to 'long'  
  
in ECPG test files.  This is because void* and long are cast back and  
forth, but on 64-bit Windows, these have different sizes.  Fix by  
using intptr_t instead.  
  
The code actually worked fine because the integer values in use are  
all small.  So this is just to get the test code to compile warning-free.  
  
This change is simplified by having made stdint.h required (commit  
957338418b69e9774ccc1bab59f765a62f0aa6f9).  Before this it would have  
been more complicated because the ecpg test source files don't use the  
full pg_config.h.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/5d398bbb-262a-5fed-d839-d0e5cff3c0d7%402ndquadrant.com  

commit   : b7fabe80df9a65010bfe5e5d0a979bacebfec382    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 20 Feb 2020 17:04:19 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 20 Feb 2020 17:04:19 -0800    

Commit 5b618e1f made an unintended behavior change.  

commit   : 032f9ae012d87c730be0e261a6bae9323c2b2d6c    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 21 Feb 2020 20:00:45 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 21 Feb 2020 20:00:45 +0900    

Previously, partition_bounds_copy() checked whether the strategy for the  
given partition bounds was hash or not, and then determined the number of  
elements in the datums in the datums array for the partition bounds, on  
each iteration of the loop for copying the datums array, but there is no  
need to do that.  Perform the checks only once before the loop iteration.  
  
Author: Etsuro Fujita  
Reported-by: Amit Langote and Julien Rouhaud  
Discussion: https://postgr.es/m/CAPmGK14Rvxrm8DHWvCjdoks6nwZuHBPvMnWZ6rkEx2KhFeEoPQ@mail.gmail.com  

commit   : 957338418b69e9774ccc1bab59f765a62f0aa6f9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 09:14:03 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 Feb 2020 09:14:03 +0100    

stdint.h belongs to the compiler (as opposed to inttypes.h), so by  
requiring a C99 compiler we can also require stdint.h  
unconditionally.  Remove configure checks and other workarounds for  
it.  
  
This also removes a few steps in the required portability adjustments  
to the imported time zone code, which can be applied on the next  
import.  
  
When using GCC on a platform that is otherwise pre-C99, this will now  
require at least GCC 4.5, which is the first release that supplied a  
standard-conforming stdint.h if the native platform didn't have it.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/5d398bbb-262a-5fed-d839-d0e5cff3c0d7%402ndquadrant.com  

commit   : dca3911a81f0ba823b56c3d4462419c83f385e55    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2020 12:05:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2020 12:05:29 +0900    

The documentation included some outdated instructions to change the  
architecture, build type or target OS of a build done with MSVC.  This  
commit updates the documentation to include the modern options  
available, down to Visual Studio 2013.  
  
Reported-by: Kyotaro Horiguchi  
Author: Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/CAC+AXB0J7tAqW_2F1fCE4Dh2=Ccz96TcLpsGXOCvka7VvWG9Qw@mail.gmail.com  
Backpatch-through: 12  

commit   : b2304a71748a3e664a1b8354d746f28c38aaa816    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Feb 2020 14:14:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Feb 2020 14:14:20 -0300    

Avoid a join between relations having the FK to detect FK violation.  
The planner might optimize this considering the PK must exist on the  
referenced side at some point, effectively masking a bug this test  
tries to detect.  
  
Tom Lane and Jehan-Guillaume de Rorthais  
Discussion: https://postgr.es/m/467.1581270529@sss.pgh.pa.us  

commit   : 53b01acd463d64c385db0ab728b8cc336549a315    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 20 Feb 2020 19:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 20 Feb 2020 19:15:00 +0900    

commit   : d55e9ae2633ee462d554dddc08d640d725dd6494    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2020 11:57:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2020 11:57:41 +0900    

e2e0219 has removed a code path for Windows 2000 that attempts to load  
wship6.dll as fallback if ws2_32.dll is found but not getaddrinfo(),  
leaving behind a dangling pointer as the library is freed.  However,  
there is no point in this check as ws2_32.dll exists since Windows XP,  
so just remove the duplicated check.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/9781.1582146114@sss.pgh.pa.us  

commit   : 6a8e5605b53561464c53006337596699f41b1de2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 18:52:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 18:52:18 -0500    

Creating a bunch of non-overlapping partial indexes is generally  
a bad idea, so add an example saying not to do that.  
  
Back-patch to v10.  Before that, the alternative of using (real)  
partitioning wasn't available, so that the tradeoff isn't quite  
so clear cut.  
  
Discussion: https://postgr.es/m/CAKVFrvFY-f7kgwMRMiPLbPYMmgjc8Y2jjUGK_Y0HVcYAmU6ymg@mail.gmail.com  

commit   : 70a7732007bc4689f4c7a44e738eb2d892dac1e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 16:59:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 16:59:14 -0500    

Andres Freund pointed out that allowing non-superusers to run  
"CREATE EXTENSION ... FROM unpackaged" has security risks, since  
the unpackaged-to-1.0 scripts don't try to verify that the existing  
objects they're modifying are what they expect.  Just attaching such  
objects to an extension doesn't seem too dangerous, but some of them  
do more than that.  
  
We could have resolved this, perhaps, by still requiring superuser  
privilege to use the FROM option.  However, it's fair to ask just what  
we're accomplishing by continuing to lug the unpackaged-to-1.0 scripts  
forward.  None of them have received any real testing since 9.1 days,  
so they may not even work anymore (even assuming that one could still  
load the previous "loose" object definitions into a v13 database).  
And an installation that's trying to go from pre-9.1 to v13 or later  
in one jump is going to have worse compatibility problems than whether  
there's a trivial way to convert their contrib modules into extension  
style.  
  
Hence, let's just drop both those scripts and the core-code support  
for "CREATE EXTENSION ... FROM".  
  
Discussion: https://postgr.es/m/20200213233015.r6rnubcvl4egdh5r@alap3.anarazel.de  

commit   : 2f9c46a32b43d72c9384378827ee51fde896807c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Feb 2020 20:52:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Feb 2020 20:52:42 +0100    

Reported-by: Daniel Verite <daniel@manitou-mail.org>  

commit   : 761a5688b179d46091e7314458571c5fc537084a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 14:44:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2020 14:44:58 -0500    

The function hash table keys made by compute_function_hashkey() failed  
to distinguish event-trigger call context from regular call context.  
This meant that once we'd successfully made a hash entry for an event  
trigger (either by validation, or by normal use as an event trigger),  
an attempt to call the trigger function as a plain function would  
find this hash entry and thereby bypass the you-can't-do-that check in  
do_compile().  Thus we'd attempt to execute the function, leading to  
strange errors or even crashes, depending on function contents and  
server version.  
  
To fix, add an isEventTrigger field to PLpgSQL_func_hashkey,  
paralleling the longstanding infrastructure for regular triggers.  
This fits into what had been pad space, so there's no risk of an ABI  
break, even assuming that any third-party code is looking at these  
hash keys.  (I considered replacing isTrigger with a PLpgSQL_trigtype  
enum field, but felt that that carried some API/ABI risk.  Maybe we  
should change it in HEAD though.)  
  
Per bug #16266 from Alexander Lakhin.  This has been broken since  
event triggers were invented, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16266-fcd7f838e97ba5d4@postgresql.org  

commit   : 2ed19a488edb3980e054e6064e7028ccb652e5df    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Feb 2020 20:09:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Feb 2020 20:09:32 +0100    

It was set to immutable.  This was a mistake in the initial  
commit (5925e5549890416bcf588334d9d0bc99f8ad6c7f).  
  
Reported-by: hubert depesz lubaczewski <depesz@depesz.com>  
Discussion: https://www.postgresql.org/message-id/flat/20200218185452.GA8710%40depesz.com  

commit   : 5b618e1f48aecc66e3a9f60289491da520faae19    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 19 Feb 2020 10:15:16 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 19 Feb 2020 10:15:16 -0800    

  * Separate calculation of hash value from the lookup.  
  * Split build_hash_table() into two functions.  
  * Change lookup_hash_entry() to return AggStatePerGroup. That's all  
    the caller needed, anyway.  
  
These changes are to support the upcoming Disk-based Hash Aggregation  
work.  
  
Discussion: https://postgr.es/m/31f5ab871a3ad5a1a91a7a797651f20e77ac7ce3.camel%40j-davis.com  

commit   : 8021985d791902a9eeda51acdede759fbc67ae01    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 18 Feb 2020 12:31:24 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 18 Feb 2020 12:31:24 -0800    

Prior to this commit, the read buffer was allocated at the time the tape  
was rewound; but as an optimization, would not be allocated at all if  
the tape was empty.  
  
That optimization meant that it was valid to have a rewound tape with  
the buffer set to NULL, but only if a number of conditions were met  
and only if the API was used properly. After 7fdd919a refactored the  
code to support lazily-allocating the buffer, Coverity started  
complaining.  
  
The optimization for empty tapes doesn't seem important, so just  
allocate the buffer whether the tape has any data or not.  
  
Discussion: https://postgr.es/m/20351.1581868306%40sss.pgh.pa.us  

commit   : 007491979461ff10d487e1da9bcc87f2fd834f26    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Feb 2020 20:37:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Feb 2020 20:37:26 +0900    

VACUUM may truncate heap in several batches. The activity report  
is logged for each batch, and contains the number of pages in the table  
before and after the truncation, and also the elapsed time during  
the truncation. Previously the elapsed time reported in each batch was  
the total elapsed time since starting the truncation until finishing  
each batch. For example, if the truncation was processed dividing into  
three batches, the second batch reported the accumulated time elapsed  
during both first and second batches. This is strange and confusing  
because the number of pages in the table reported together is not  
total. Instead, each batch should report the time elapsed during  
only that batch.  
  
The cause of this issue was that the resource usage snapshot was  
initialized only at the beginning of the truncation and was never  
reset later. This commit fixes the issue by changing VACUUM so that  
the resource usage snapshot is reset at each batch.  
  
Back-patch to all supported branches.  
  
Reported-by: Tatsuhito Kasahara  
Author: Tatsuhito Kasahara  
Reviewed-by: Masahiko Sawada, Fujii Masao  
Discussion: https://postgr.es/m/CAP0=ZVJsf=NvQuy+QXQZ7B=ZVLoDV_JzsVC1FRsF1G18i3zMGg@mail.gmail.com  

commit   : e2e02191e23379502a38a6b0436ab7f41b2efc08    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2020 13:20:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2020 13:20:33 +0900    

This fixes and updates a couple of comments related to outdated Windows  
versions.  Particularly, src/common/exec.c had a fallback implementation  
to read a file's line from a pipe because stdin/stdout/stderr does not  
exist in Windows 2000 that is removed to simplify src/common/ as there  
are unlikely versions of Postgres running on such platforms.  
  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/20191219021526.GC4202@paquier.xyz  

commit   : e3ff789acfb2754cd7b5e87f6f4463fd08e35996    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 12 Feb 2020 11:23:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 12 Feb 2020 11:23:24 +0530    

Manifested as  
  
ERROR:  subtransaction logged without previous top-level txn record  
  
this check forbids legit behaviours like  
 - First xl_xact_assignment record is beyond reading, i.e. earlier  
   restart_lsn.  
 - After restart_lsn there is some change of a subxact.  
 - After that, there is second xl_xact_assignment (for another subxact)  
   revealing the relationship between top and first subxact.  
  
Such a transaction won't be streamed anyway because we hadn't seen it in  
full.  Saying for sure whether xact of some record encountered after  
the snapshot was deserialized can be streamed or not requires to know  
whether it wrote something before deserialization point --if yes, it  
hasn't been seen in full and can't be decoded. Snapshot doesn't have such  
info, so there is no easy way to relax the check.  
  
Reported-by: Hsu, John  
Diagnosed-by: Arseny Sher  
Author: Arseny Sher, Amit Kapila  
Reviewed-by: Amit Kapila, Dilip Kumar  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/AB5978B2-1772-4FEE-A245-74C91704ECB0@amazon.com  

commit   : fe9b92854e7d5f66d3abb565c5b60a879b6c9442    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 18 Feb 2020 16:07:16 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 18 Feb 2020 16:07:16 -0800    

btbuild() has nothing to say about how NULL values compare in nbtree.  
Besides, there are _bt_compare() header comments that describe how NULL  
values are handled.  

commit   : b7e51b350c4e6b1cb3404588cf11801525e2336f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 18 Feb 2020 13:13:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 18 Feb 2020 13:13:15 +0900    

Previously, LOCK TABLE command through a parent table checked  
the permissions on not only the parent table but also the children  
tables inherited from it. This was a bug and inherited queries should  
perform access permission checks on the parent table only. This  
commit fixes LOCK TABLE so that it does not check the permission  
on children tables.  
  
This patch is applied only in the master branch. We decided not to  
back-patch because it's not hard to imagine that there are some  
applications expecting the old behavior and the change breaks their  
security.  
  
Author: Amit Langote  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAHGQGwE+GauyG7POtRfRwwthAGwTjPQYdFHR97+LzA4RHGnJxA@mail.gmail.com  

commit   : 958f9fb98da97a1d781a3766ea86bcdba3b216c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Feb 2020 12:20:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Feb 2020 12:20:55 +0900    

Author: Daniel Gustafsson  
Reviewed-by: Vik Fearing  
Discussion: https://postgr.es/m/EBC3BFEB-664C-4063-81ED-29F1227DB012@yesql.se  

commit   : ddfc3c1499b05956094a7f219fe2b6ac0c9ce5eb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Feb 2020 10:49:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Feb 2020 10:49:44 +0900    

This is related to progress reporting for ANALYZE and partitioned  
tables.  
  
Author: Amit Langote  
Reviewed-by: Daniel Gustafsson, Julien Rouhaud  
Discussion: https://postgr.es/m/CA+HiwqGx6C=-bFTX=ryMThyvM7CcSC3b1x8_6zh4Uo41Kvu-zw@mail.gmail.com  

commit   : f31364676dfd9e7a2b712ea0da7b4ab6b7d28f5e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2020 18:40:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2020 18:40:02 -0500    

This was unaccountably omitted in the original RLS patch.  
The SQL syntax is basically the same as for comments on triggers,  
so crib code from dumpTrigger().  
  
Per report from Marc Munro.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1581889298.18009.15.camel@bloodnok.com  

commit   : c6679e4fca21d253ced84c51ac1a31c1b2aec72f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 15:19:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 15:19:58 +0100    

When updating a table row with generated columns, only recompute those  
generated columns whose base columns have changed in this update and  
keep the rest unchanged.  This can result in a significant performance  
benefit.  The required information was already kept in  
RangeTblEntry.extraUpdatedCols; we just have to make use of it.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/b05e781a-fa16-6b52-6738-761181204567@2ndquadrant.com  

commit   : ad3ae64770e5b4391ad07fb2a689d72aa45b4689    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 15:19:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Feb 2020 15:19:58 +0100    

The extraUpdatedCols field of the target RTE records which generated  
columns are affected by an update.  This is used in a variety of  
places, including per-column triggers and foreign data wrappers.  When  
an update was initiated by a logical replication subscription, this  
field was not filled in, so such an update would not affect generated  
columns in a way that is consistent with normal updates.  To fix,  
factor out some code from analyze.c to fill in extraUpdatedCols in the  
logical replication worker as well.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/b05e781a-fa16-6b52-6738-761181204567@2ndquadrant.com  

commit   : f4ae7221413d5176e4d5a49883217ea87312104a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Feb 2020 16:16:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Feb 2020 16:16:08 +0900    

This commit also updates wait event enum into alphabetical order.  
Previously the enum entry for GSSOpenServer was added out-of-order.  
  
Back-patch to v12 where commit b0b39f72b9 introduced  
GSSOpenServer wait event. In v12, the commit doesn't include  
the update of wait event enum, not to break ABI.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/949931aa-4ed4-d867-a7b5-de9c02b2292b@oss.nttdata.com  

commit   : e593148d43adb8ef1721ccd987046c02f4532920    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Feb 2020 15:33:32 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Feb 2020 15:33:32 +0900    

Back-patch to v10 where commit 249cf070e3 introduced  
LogicalRewriteTruncate wait event.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/949931aa-4ed4-d867-a7b5-de9c02b2292b@oss.nttdata.com  

commit   : e02ea141ee66e5b2372e1eb2d2000b7ed3a8e13a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2020 12:20:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2020 12:20:18 -0500    

Commit 0da33c762 introduced an unfortunate regression in pg_ctl on  
Windows: if the log file specified with -l doesn't exist yet, and  
pg_ctl is running with Administrator privileges, then the log file  
might get created with permissions that prevent the postmaster from  
writing on it.  (It seems that whether this happens depends on whether  
the log file is inside the user's home directory or not, and perhaps  
on other phase-of-the-moon conditions, which may explain why we failed  
to notice it sooner.)  
  
To fix, just don't create the log file if it doesn't exist yet.  The  
case where we need to wait obviously only occurs with a pre-existing  
log file.  
  
In passing, switch from using fopen() to plain open(), saving a few  
cycles.  
  
Per bug #16259 from Jonathan Katz and Heath Lord.  Back-patch to v12,  
as the faulty commit was.  
  
Alexander Lakhin  
  
Discussion: https://postgr.es/m/16259-c5ebed32a262a8b1@postgresql.org  

commit   : faade5d4c6d8b4f7d46f91702a57529c96aee86e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 15:22:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 15:22:40 -0500    

Noted by Justin Pryzby, though I chose to just rip out the stale text,  
as it's in no way relevant to this particular function.  
  
Discussion: https://postgr.es/m/20200212182337.GZ1412@telsasoft.com  

commit   : 9d1ec5a8e155a996a81b5fecc3da803ecb94d8ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 15:13:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 15:13:44 -0500    

Make it a bit shorter and better-commented; no functional change.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/20200212182337.GZ1412@telsasoft.com  

commit   : b78542b9e975494bba6db2d2802439c3328d5ef7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 14:58:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 14:58:30 -0500    

Mostly to make sure the previous commit didn't break this.  
  
Discussion: https://postgr.es/m/20200212182337.GZ1412@telsasoft.com  

commit   : 86ff085e83888e2e359620fc326608a674423308    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 14:57:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2020 14:57:27 -0500    

Practically everybody who's ever added a column to one of the bootstrap  
catalogs has been burnt by the need to update the relnatts field in the  
initial pg_class data to match.  Now that we use Perl scripts to  
generate postgres.bki, we can have the machines take care of that,  
by filling the field during genbki.pl.  
  
While at it, use the BKI_DEFAULTS mechanism to eliminate repetitive  
specifications of other column values in pg_class.dat, too.  They  
weren't particularly a maintenance problem, but this way is prettier  
(certainly the spotty previous usage of BKI_DEFAULTS wasn't pretty).  
  
No catversion bump needed, since this doesn't actually change the  
contents of postgres.bki.  
  
Per gripe from Justin Pryzby, though this is quite different from  
his originally proposed solution.  
  
Amit Langote, John Naylor, Tom Lane  
  
Discussion: https://postgr.es/m/20200212182337.GZ1412@telsasoft.com  

commit   : 317906f2a634090a79ca95d5816931c4ce8dca5a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 Feb 2020 18:38:35 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 Feb 2020 18:38:35 -0800    

The stylesheets used for the HTML documentation rendered on  
postgresql.org have shifted, and no longer matched what was expected by  
"make STYLE=website html" builds performed locally.  Local doc builds  
did not reflect other aspects of the website, including font and  
margins.  
  
This patch updates the references to use the current set of stylesheets  
that are used by the documentation on postgresql.org. This also wraps  
the documentation preview in a HTML container so it can keep the content  
within similar margins to those found on the website.  
  
The documentation on building the docs is updated to reflect this  
change, and to let the documentation builder know that an external  
network connection is required to properly preview documentation built  
with "make STYLE=website html" (which was true prior to this patch too,  
but not mentioned).  
  
Author: Jonathan Katz  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/1375.1581446233@sss.pgh.pa.us  

commit   : 751c63cea0befe292fafd9a4a1f16dfa2f1746f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2020 11:20:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2020 11:20:07 -0500    

We haven't used this option since inventing extensions.  As of commit  
50fc694e4 it's actually formally equivalent to --load-extension, so  
let's just drop it.  
  
Discussion: https://postgr.es/m/6853.1581627393@sss.pgh.pa.us  

commit   : 11f063b0a974f4e1c87c26d0fe259c2167f3d00e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Feb 2020 12:38:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Feb 2020 12:38:44 +0900    

Since its introduction in fe59e56, the code in charge of validating and  
converting a file path includes some extra handling for absolute paths  
pointing to an external log_directory, but this has never been used.  
  
Author: Antonin Houska  
Reviewed-by: Julien Rouhaud, Michael Paquier  
Discussion: https://postgr.es/m/32663.1581592539@antos  

commit   : eb67623c965b4759a96309cdb58a17339fc5d401    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2020 15:02:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2020 15:02:35 -0500    

This allows these modules to be installed into a database without  
superuser privileges (assuming that the DBA or sysadmin has installed  
the module's files in the expected place).  You only need CREATE  
privilege on the current database, which by default would be  
available to the database owner.  
  
The following modules are marked trusted:  
  
btree_gin  
btree_gist  
citext  
cube  
dict_int  
earthdistance  
fuzzystrmatch  
hstore  
hstore_plperl  
intarray  
isn  
jsonb_plperl  
lo  
ltree  
pg_trgm  
pgcrypto  
seg  
tablefunc  
tcn  
tsm_system_rows  
tsm_system_time  
unaccent  
uuid-ossp  
  
In the future we might mark some more modules trusted, but there  
seems to be no debate about these, and on the whole it seems wise  
to be conservative with use of this feature to start out with.  
  
Discussion: https://postgr.es/m/32315.1580326876@sss.pgh.pa.us  

commit   : 7fdd919ae7550f478e7ae4031f7f439278cf2282    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 13 Feb 2020 09:43:51 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 13 Feb 2020 09:43:51 -0800    

The write buffer was already lazily-allocated, so this is more  
symmetric. It also means that a freshly-rewound tape (whether for  
reading or writing) is not consuming memory for the buffer.  
  
Discussion: https://postgr.es/m/97c46a59c27f3c38e486ca170fcbc618d97ab049.camel%40j-davis.com  

commit   : 607f8ce74df9d5a4a7a3c65235909794cdc1d1d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2020 13:37:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2020 13:37:43 -0500    

Commit 6bf0bc842 replaced float.c's CHECKFLOATVAL() macro with static  
inline subroutines, but that wasn't too well thought out.  In the original  
coding, the unlikely condition (isinf(result) or result == 0) was checked  
first, and the inf_is_valid or zero_is_valid condition only afterwards.  
The inline-subroutine coding caused that to be swapped around, which is  
pretty horrid for performance because (a) in common cases the is_valid  
condition is twice as expensive to evaluate (e.g., requiring two isinf()  
calls not one) and (b) in common cases the is_valid condition is false,  
requiring us to perform the unlikely-condition check anyway.  Net result  
is that one isinf() call becomes two or three, resulting in visible  
performance loss as reported by Keisuke Kuroda.  
  
The original fix proposal was to revert the replacement of the macro,  
but on second thought, that macro was just a bad idea from the beginning:  
if anything it's a net negative for readability of the code.  So instead,  
let's just open-code all the overflow/underflow tests, being careful to  
test the unlikely condition first (and mark it unlikely() to help the  
compiler get the point).  
  
Also, rather than having N copies of the actual ereport() calls, collapse  
those into out-of-line error subroutines to save some code space.  This  
does mean that the error file/line numbers won't be very helpful for  
figuring out where the issue really is --- but we'd already burned that  
bridge by putting the ereports into static inlines.  
  
In HEAD, check_float[48]_val() are gone altogether.  In v12, leave them  
present in float.h but unused in the core code, just in case some  
extension is depending on them.  
  
Emre Hasegeli, with some kibitzing from me and Andres Freund  
  
Discussion: https://postgr.es/m/CANDwggLe1Gc1OrRqvPfGE=kM9K0FSfia0hbeFCEmwabhLz95AA@mail.gmail.com  

commit   : caba0910afa124b8c6c61208b487846eea6b1970    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 12 Feb 2020 14:08:34 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 12 Feb 2020 14:08:34 -0800    

Use a top-level "variablelist", with one item per B-Tree support  
function.  This structure matches the structure used by various  
"Extensibility" sections in other documentation chapters for other index  
access methods.  
  
An explicit list makes it much clearer where each item begins and ends.  
This wasn't really a problem before now, but an upcoming patch that adds  
deduplication to nbtree will need to have its own new B-Tree support  
function.  Ease the burden of translators by tidying up btree.sgml ahead  
of committing the deduplication patch.  

commit   : 0973f5602c349ad99fae6f57cdcc26754a03ba83    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2020 14:33:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2020 14:33:49 -0500    

These should've been dropped by a8bb8eb58, but evidently were  
missed.  Not important enough to back-patch.  

commit   : dce988145f7e455f224310afec6b06bcf3eed24e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2020 14:13:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2020 14:13:13 -0500    

The GRANTED BY clause in GRANT/REVOKE ROLE has been there since 2005  
but was never documented.  I'm not sure now whether that was just an  
oversight or was intentional (given the limited capability of the  
option).  But seeing that pg_dumpall does emit code that uses this  
option, it seems like not documenting it at all is a bad idea.  
  
Also, when we upgraded the syntax to allow CURRENT_USER/SESSION_USER  
as the privilege recipient, the role form of GRANT was incorrectly  
not modified to show that, and REVOKE's docs weren't touched at all.  
  
Although I'm not that excited about GRANTED BY, the other oversight  
seems serious enough to justify a back-patch.  
  
Discussion: https://postgr.es/m/3070.1581526786@sss.pgh.pa.us  

commit   : 997563dfcb2501a7a199589cd6f15f2bb8af3d04    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Feb 2020 21:14:08 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Feb 2020 21:14:08 -0800    

Looks like guaibasaurus had a autovacuum running during the  
controller_print_speculative_locks step (just added in  
43e08419708). Which does indeed seem quite possible.  
  
Avoid the problem by only looking for the backends participating in  
the test.  

commit   : dcdbb5a5db09064ac08ff3971c5031281ef2e545    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Feb 2020 13:31:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Feb 2020 13:31:14 +0900    

%d can be used to track if the current connection is in a transaction  
block or not, and adding it by default to the prompt has the advantage  
to not need a modification of .psqlrc, something not possible depending  
on the environment.  
  
This discussion has happened across various sources, and there was a  
strong consensus in favor of this change.  
  
Author: Vik Fearing  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/09502c40-cfe1-bb29-10f9-4b3fa7b2bbb2@2ndquadrant.com  

commit   : 43e08419708a938236e76cd50de2db512e1c3a0c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Feb 2020 16:32:11 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Feb 2020 16:32:11 -0800    

Previously, the speculative insert tests did not cover the case when a  
tuple t is inserted into a table with a unique index on a column but  
before it can insert into the index, a concurrent transaction has  
inserted a conflicting value into the index and the insertion of tuple t  
must be aborted.  
  
The basic permutation is one session successfully inserts into the table  
and an associated unique index while a concurrent session successfully  
inserts into the table but discovers a conflict before inserting into  
the index and must abort the insertion.  
  
Several variants on this include:  
- swap which session is successful  
- first session insert transaction does not commit, so second session  
must wait on a transaction lock  
- first session insert does not "complete", so second session must wait  
on a speculative insertion lock  
  
Also, refactor the existing TOAST table upsert test to be in the same  
spec and reuse the steps.  
  
Author: Melanie Plageman, Ashwin Agrawal, Andres Freund  
Reviewed-by: Andres Freund, Taylor Vesely  
Discussion: https://postgr.es/m/CAAKRu_ZRmxy_OEryfY3G8Zp01ouhgw59_-_Cm8n7LzRH5BAvng@mail.gmail.com  

commit   : be6221e9be234109aa261ea767c85f5e8cda90e8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 12 Feb 2020 09:08:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 12 Feb 2020 09:08:22 +0900    

Commit caba97a9d9 changed pg_basebackup -F plain -R so that  
it overwrote postgresql.auto.conf in the backup, with new connection  
setting. This could cause the existing postgresql.auto.conf settings  
in the server to get lost unexpectedly. This is a bug.  
  
This commit fixes the bug by making pg_basebackup -F plain -R  
append the connection setting into postgresql.auto.conf in the backup.  
  
Author: Fujii Masao  
Reviewed-by: Sergei Kornilov  
Discussion: https://postgr.es/m/250dcf2a-94e7-c05e-824a-73cfb38a48a4@oss.nttdata.com  

commit   : e49d5ebbaebc3ecd6b495fda9518c2c2fac5c296    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 11 Feb 2020 23:47:36 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 11 Feb 2020 23:47:36 +0100    

commit   : 701a51fd4e01dbbd02067d8f01905a04bc571131    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 11 Feb 2020 17:22:37 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 11 Feb 2020 17:22:37 +1300    

This removes some lseek() system calls.  
  
Author: Thomas Munro  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKGJ%2BoHhnvqjn3%3DHro7xu-YDR8FPr0FL6LF35kHRX%3D_bUzg%40mail.gmail.com  

commit   : 2102ba4b586350957bf95b371432583239000164    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 20:47:50 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 20:47:50 +0100    

commit   : 541757f34ee099dd8e601b29dfad6302c6747d71    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 19:27:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 19:27:05 +0100    

This use was not protecting any unportable code, it was just omitting  
the code because it wouldn't be used.  Remove the use to reduce code  
complexity a bit.  
  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : b691c189c671ca9b88743ed6546b60641e5199e4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 17:12:46 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2020 17:12:46 +0100    

The previous system had configure put the value into the makefiles and  
then have the makefiles pass them to the build of pg_config.  That was  
put in place when pg_config was a shell script.  We can simplify that  
by having configure put the value into pg_config.h directly.  This  
also makes the standard build system match how the MSVC build system  
already does it.  
  
Discussion: https://www.postgresql.org/message-id/flat/6e457870-cef5-5f1d-b57c-fc89cfb8a788%402ndquadrant.com  

commit   : 11de6c903da99a4b2220acfa776fc26c7f384ccc    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 10 Feb 2020 10:20:10 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 10 Feb 2020 10:20:10 -0800    

Commit 4eaea3db introduced TupleHashTableHash(), but the signature  
didn't match the other exposed functions. Separate it into internal  
and external versions. The external version hides the details behind  
an API more consistent with the other external functions, and the  
internal version is still suitable for simplehash.  

commit   : 8fa8e011563744f61d29024ab187a189124a6551    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Feb 2020 12:14:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Feb 2020 12:14:58 -0300    

The original coding failed to quote the argument properly.  
  
Reported-by: Daniel Gustafsson  
Discussion: 1B8AE66C-85AB-4728-9BB4-612E8E61C219@yesql.se  

commit   : b048f558dd7c26a0c630a2cff29d3d8981eaf6b9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Feb 2020 11:47:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Feb 2020 11:47:09 -0300    

Marking an object as dependant on an extension did not have any  
privilege check whatsoever; this allowed any user to mark objects as  
droppable by anyone able to DROP EXTENSION, which could be used to cause  
system-wide havoc.  Disallow by checking that the calling user owns the  
mentioned object.  
  
(No constraints are placed on the extension.)  
  
Security: CVE-2020-1720  
Reported-by: Tom Lane  
Discussion: 31605.1566429043@sss.pgh.pa.us  

commit   : 4e818866e57aa9ec13821fd36a2ff60e00e6dea6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Feb 2020 15:48:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Feb 2020 15:48:21 +0900    

This reverts commit d1c0b61.  The patch has some downsides that require  
more attention, as discussed with Noah Misch.  
  
Backpatch-through: 9.5  

commit   : 3dfba9fdf52121e777e83f27120a755f408927ed    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 10 Feb 2020 09:31:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 10 Feb 2020 09:31:18 +0530    

Reported-by: Justin Pryzby  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200206021432.GA24549@telsasoft.com  

commit   : 77a00b809a03fbc80957815bbd9092aa9a7748e3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 10 Feb 2020 08:34:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 10 Feb 2020 08:34:43 +0530    

Reported-by: Justin Pryzby  
Author: Justin Pryzby  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/20200206021432.GA24549@telsasoft.com  

commit   : d1c0b6132839e496eea73383813a127833af72f1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Feb 2020 10:48:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Feb 2020 10:48:43 +0900    

The previous coding forgot to apply shell quoting to the socket  
directory and the data folder, leading to failures when running  
pg_upgrade.  This refactors the code generating the pg_ctl command  
starting clusters to use a more correct shell quoting.  Failures are  
easier to trigger in 12 and newer versions by using a value of  
--socketdir that includes quotes, but it is also possible to cause  
failures with quotes included in the default socket directory used by  
pg_upgrade or the data folders of the clusters involved in the  
upgrade.  
  
As 9.4 is going to be EOL'd with the next minor release, nobody is  
likely going to upgrade to it now so this branch is not included in the  
set of branches fixed.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Noah Misch  
Backpatch-through: 9.5  

commit   : 1713a0013f909d9ce5dd43d234f1cd33d6a50854    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 10 Feb 2020 13:20:00 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 10 Feb 2020 13:20:00 +1300    

The width of the invisible PROMPT2 must take into account, in order  
for user input to be aligned with the first line, that PROMPT1 can  
contain newlines.  
  
Author: Maxence Ahlouche  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAJeaomVyLSP_Wj%3D0FtYNTuoopWHyFarhUtYKDHs0HHv%2Bb%3DN9sA%40mail.gmail.com  

commit   : c185a57753e64fe3ffc996ea18da8672b302a5a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2020 14:19:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2020 14:19:46 -0500    

This reverts commit 0e936a2148472e6c364aee8c3e298dc16dc4240a.  
  
Per discussion, we can't change the section title without some  
web-site work, so revert this change temporarily.  
  
Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538@wrigleys.postgresql.org  

commit   : 4093ff573702e9f157507340593680dc2c75e88e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2020 12:02:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2020 12:02:57 -0500    

Commit b10714080 moved the GinPageSetDeleteXid() call to a spot where  
the "page" variable was pointing to the wrong page, causing the XID  
to be inserted on a page that's not being deleted, thus allowing later  
GinPageIsRecyclable tests to recycle the deleted page too soon.  
  
It might be a good idea to stop using the single "page" variable for  
multiple purposes in this function.  But for the moment I just moved  
the GinPageSetDeleteXid() call down beside the GinPageSetDeleted()  
call, which seems like a more logical place for it anyway.  
  
Back-patch to v11, as the faulty patch was.  (Fortunately, the bug  
hasn't made it into any release yet.)  
  
Discussion: https://postgr.es/m/21620.1581098806@sss.pgh.pa.us  

commit   : 55173d2e663fbe32430665ce7bd65a47856dc237    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Feb 2020 18:27:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Feb 2020 18:27:18 -0300    

On a multi-level partioned table, when adding a partition not directly  
connected to the root table, foreign key constraints referencing the  
root were not cloned to the new partition, leading to the FK being  
possibly inadvertently violated later on.  
  
This was caused by fuzzy thinking in CloneFkReferenced (commit  
f56f8f8da6af): it was skipping constraints marked as having parents on  
the theory that cloning those would create duplicates; but that's only  
correct for the top level of the partitioning hierarchy.  For levels  
below that one, such constraints must still be considered and only  
skipped if later on we see that we'd create duplicates.  Apparently, I  
(Álvaro) wrote the comments right but the code implemented something  
slightly different.  
  
Author: Jehan-Guillaume de Rorthais  
Discussion: https://postgr.es/m/20200206004948.238352db@firost  

commit   : 9710d3d4a87f428a10f63015a0d75ccf028dd137    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Feb 2020 17:09:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Feb 2020 17:09:36 -0300    

When running TRUNCATE CASCADE on a child of a partitioned table  
referenced by another partitioned table, the truncate was not applied to  
partitions of the referencing table; this could leave rows violating the  
constraint in the referencing partitioned table.  Repair by walking the  
pg_constraint chain all the way up to the topmost referencing table.  
  
Note: any partitioned tables containing FKs that reference other  
partitioned tables should be checked for possible violating rows, if  
TRUNCATE has occurred in partitions of the referenced table.  
  
Reported-by: Christophe Courtois  
Author: Jehan-Guillaume de Rorthais  
Discussion: https://postgr.es/m/20200204183906.115f693e@firost  

commit   : cb5b28613d553b1c750622e91cbc96c83f052a63    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Feb 2020 22:00:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Feb 2020 22:00:21 +0900    

Commit 147e3722f7 changed Tid scan so that it calls table_beginscan()  
and uses the scan option for seq scan. This change caused two issues.  
  
(1) The change caused Tid scan to take a predicate lock on the entire  
       relation in serializable transaction even when relation-level  
       lock is not necessary. This could lead to an unexpected  
       serialization error.  
  
(2) The change caused Tid scan to increment the number of seq_scan  
       in pg_stat_*_tables views even though it's not seq scan. This  
       could confuse the users.  
  
This commit adds the scan option for Tid scan and makes Tid scan  
use it, to avoid those issues.  
  
Back-patch to v12, where the bug was introduced.  
  
Author: Tatsuhito Kasahara  
Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada, Fujii Masao  
Discussion: https://postgr.es/m/CAP0=ZVKy+gTbFmB6X_UW0pP3WaeJ-fkUWHoD-pExS=at3CY76g@mail.gmail.com  

commit   : b059d2f45685a946da061ee15692fa306bd67f12    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 22:13:52 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 22:13:52 -0800    

The main benefit of doing so is that this allows llvm to ensure that  
types match - previously that'd only be detected by a crash within the  
called function. There were a number of cases where we passed a  
superfluous parameter...  
  
To avoid needing to add all the functions to llvmjit.{c,h}, instead  
get them from the llvm module for llvmjit_types.c. Also use that for  
the functions from llvmjit_types already in llvmjit.h.  
  
Author: Soumyadeep Chakraborty and Andres Freund  
Discussion: https://postgr.es/m/CADwEdooww3wZv-sXSfatzFRwMuwa186LyTwkBfwEW6NjtooBPA@mail.gmail.com  

commit   : c4f3b63caba02b087519d58cb9bf4990b9c8ec45    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 15:08:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 15:08:17 +0900    

Oversight in commit b025f32.  
  
Per private report from Julien Rouhaud.  

commit   : 4eaea3db150af56aa2e40efe91997fd25f3b6d73    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 19:39:47 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 19:39:47 -0800    

Expose two new entry points: one for only calculating the hash value  
of a tuple, and another for looking up a hash entry when the hash  
value is already known. This will be useful for disk-based Hash  
Aggregation to avoid recomputing the hash value for the same tuple  
after saving and restoring it from disk.  
  
Discussion: https://postgr.es/m/37091115219dd522fd9ed67333ee8ed1b7e09443.camel%40j-davis.com  

commit   : e6f86f8dd9835b18890fd8e9868884dec37e3bd7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:45:45 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:45:45 -0800    

This merges the code emission for a number of opcodes by handling the  
behavioural difference more locally. This reduces code, and also  
improves the generated code a bit in some cases, by removing redundant  
constants.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de  

commit   : 8c2769405ff1f4617b0d3af50760b1ee357733ef    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:09:06 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:09:06 -0800    

Previously we used constant function pointer addresses, which prevents  
inlining and other related optimizations.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de  

commit   : 1fdb7f9789c4550204cd62d1746a7deed1dc4c29    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:06:16 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:06:16 -0800    

It's already tracked via ExprState->parent, so we don't need to also  
include it in ExprEvalStep. When that code originally was written  
ExprState->parent didn't exist, but it since has been introduced in  
6719b238e8f.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de  

commit   : 1ec7679f1b67e84be688a311dce234eeaa1d5de8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:04:50 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Feb 2020 19:04:50 -0800    

This mostly consists of using C99 style for loops, moving variables  
into narrower scopes, and a smattering of other minor improvements.  
Done separately to make it easier to review patches with actual  
functional changes.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de  

commit   : 5ac4e9a12c6543414891cd8972b2cd36a08e40cc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 12:41:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 12:41:10 +0900    

Author: Julien Rouhaud  
Discussion: https://postgr.es/m/20200206082333.GA95343@nol  

commit   : dcddc3f813ff39d0e33c2b7c77092a6c0b0e9d0b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 10:51:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 10:51:17 +0900    

This reverts commit 7bae0ad, as this is not ideal with the tar format,  
and we may want to explore more options like what is done by tar with  
some equivalents of --owner and --group, but for pg_basebackup.  
  
Per complaints from Magnus Hagander and Stephen Frost.  
  
Discussion: https://postgr.es/m/20200205172259.GW3195@tamriel.snowman.net  

commit   : 414c2fd1e1c0ccd1af1cad046bef1264e3f4347f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 08:10:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Feb 2020 08:10:40 +0900    

This reverts commit 41aadee, as the GUC checks could run on older values  
with the new values used, and result in incorrect errors if both  
parameters are changed at the same time.  
  
Per complaint from Tom Lane.  
  
Discussion: https://postgr.es/m/27574.1581015893@sss.pgh.pa.us  
Backpatch-through: 12  

commit   : fc7a5e9eaa2fa34b053ffe52e0e57f1fd6b1f939    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Feb 2020 21:21:04 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Feb 2020 21:21:04 +0100    

In certain transient states, it's possible that a table has attributes  
with attgenerated set but no default expressions in pg_attrdef yet.  
In that case, the old code path would not set  
relation->rd_att->constr->has_generated_stored, unless  
relation->rd_att->constr was also populated for some other reason.  
There was probably no practical impact, but it's better to keep this  
consistent.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/flat/20200115181105.ad6ab6dlgyww3lb6%40alap3.anarazel.de  

commit   : 7d4395d0a11589aa450a073d658c49b420f4493f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 11:49:56 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 11:49:56 -0800    

Consolidate the calculations for hash table size estimation. This will  
help with upcoming Hash Aggregation work that will add additional call  
sites.  

commit   : c02fdc9223015c5c386abfa00c47fc7f4c845161    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 10:06:25 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 6 Feb 2020 10:06:25 -0800    

Previously, the freelist of blocks was tracked as an  
occasionally-sorted array. A min heap is more resilient to larger  
freelists or more frequent changes between reading and writing.  
  
Discussion: https://postgr.es/m/97c46a59c27f3c38e486ca170fcbc618d97ab049.camel%40j-davis.com  

commit   : cac8ce4a738a6fbc6cda4759c056f89a5b603bfc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Feb 2020 15:57:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Feb 2020 15:57:02 +0530    

Reported-by: Amit Langote  
Author: Amit Langote  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CA+HiwqFNADeukaaGRmTqANbed9Fd81gLi08AWe_F86_942Gspw@mail.gmail.com  

commit   : 3ccc66dac65e12b8f19d0766b00feabd55433854    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 6 Feb 2020 14:43:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 6 Feb 2020 14:43:21 +0900    

Previously PostgreSQL built with -DLWLOCK_STATS could report  
more than one LWLock statistics entries for the same backend  
process and the same LWLock. This is strange and only one  
statistics should be output in that case, instead.  
  
The cause of this issue is that the key variable used for  
LWLock stats hash table was not fully initialized. The key  
consists of two fields and they were initialized. But  
the following 4 bytes allocated in the key variable for  
the alignment was not initialized. So even if the same key  
was specified, hash_search(HASH_ENTER) could not find  
the existing entry for that key and created new one.  
  
This commit fixes this issue by initializing the key  
variable with zero. As the side effect of this commit,  
the volume of LWLock statistics output would be reduced  
very much.  
  
Back-patch to v10, where commit 3761fe3c20 introduced the issue.  
  
Author: Fujii Masao  
Reviewed-by: Julien Rouhaud, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/26359edb-798a-568f-d93a-6aafac49752d@oss.nttdata.com  

commit   : b025f32e0b5d7668daec9bfa957edf3599f4baa8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Feb 2020 09:18:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Feb 2020 09:18:06 +0900    

This new field tracks the PID of the group leader used with parallel  
query.  For parallel workers and the leader, the value is set to the  
PID of the group leader.  So, for the group leader, the value is the  
same as its own PID.  Note that this reflects what PGPROC stores in  
shared memory, so as leader_pid is NULL if a backend has never been  
involved in parallel query.  If the backend is using parallel query or  
has used it at least once, the value is set until the backend exits.  
  
Author: Julien Rouhaud  
Reviewed-by: Sergei Kornilov, Guillaume Lelarge, Michael Paquier, Tomas  
Vondra  
Discussion: https://postgr.es/m/CAOBaU_Yy5bt0vTPZ2_LUM6cUcGeqmYNoJ8-Rgto+c2+w3defYA@mail.gmail.com  

commit   : bf6cc19e347d4cb8dfc8f05a59171ac06e18b5e5    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Feb 2020 19:49:47 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Feb 2020 19:49:47 +0000    

Tuple conversion incorrectly concluded that no conversion was needed  
as long as all the attributes lined up. But if the source tuple has a  
missing attribute (from addition of a column with default), then the  
destination tupdesc might not reflect the same default. The typical  
symptom was that the affected columns would be unexpectedly NULL.  
  
Repair by always forcing conversion if the source has missing  
attributes, which will be filled in by the deform operation. (In  
theory we could optimize for when the destination has the same  
default, but that seemed overkill.)  
  
Backpatch to 11 where missing attributes were added.  
  
Per bug #16242.  
  
Vik Fearing (discovery, code, testing) and me (analysis, testcase).  
  
Discussion: https://postgr.es/m/16242-d1c9fca28445966b@postgresql.org  

commit   : 15d13e82911f7cc9f04f0bf419a96fd827fd1a9d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Feb 2020 16:59:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Feb 2020 16:59:29 -0300    

Using 32 bit counters means they can now realistically wrap around when  
vacuuming extremely large tables.  Because they're signed integers,  
stats printed by vacuum look very odd when they do.  
  
We'd love to backpatch this, but refrain because the variables are  
exported and could cause third-party code to break.  
  
Reviewed-by: Julien Rouhaud, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/20200131205926.GA16367@alvherre.pgsql  

commit   : 75cdf24ec3f812b2c52e0f47286665f9c8ced24b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Feb 2020 13:21:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Feb 2020 13:21:43 -0300    

The docs are ambiguous as to which tables would be copied over when the  
copy_data parameter is true in ALTER SUBSCRIPTION ... REFRESH PUBLICATION.  
Make it clear that it only applies to tables which are new in the  
publication.  
  
Author: David Christensen (reword by Álvaro Herrera)  
Discussion: https://postgr.es/m/95339420-7F09-4F8C-ACC0-8F1CFAAD9CD7@endpoint.com  

commit   : bf989aaf35613ed2c2a66e120ca600e7b9da4f82    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Feb 2020 08:26:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Feb 2020 08:26:41 -0800    

PostgresNode already retained base directories in such cases.  Stop  
using $SIG{__DIE__}, which is redundant with the exit status check, in  
lieu of proliferating it to TestLib.  Back-patch to 9.6, where commit  
88802e068017bee8cea7a5502a712794e761c7b5 introduced retention on  
failure.  
  
Reviewed by Daniel Gustafsson.  
  
Discussion: https://postgr.es/m/20200202170155.GA3264196@rfd.leadboat.com  

commit   : 815c2f0972c8386aba7c606f1ee6690d13b04db2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 5 Feb 2020 17:35:57 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 5 Feb 2020 17:35:57 +1300    

Use kevent(2) to wait for events on the BSD family of operating  
systems and macOS.  This is similar to the epoll(2) support added  
for Linux by commit 98a64d0bd.  
  
Author: Thomas Munro  
Reviewed-by: Andres Freund, Marko Tiikkaja, Tom Lane  
Tested-by: Mateusz Guzik, Matteo Beccati, Keith Fiske, Heikki Linnakangas, Michael Paquier, Peter Eisentraut, Rui DeSousa, Tom Lane, Mark Wong  
Discussion: https://postgr.es/m/CAEepm%3D37oF84-iXDTQ9MrGjENwVGds%2B5zTr38ca73kWR7ez_tA%40mail.gmail.com  

commit   : d9fe702a2c9843af71419ad0df069859e5581694    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 5 Feb 2020 12:21:03 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 5 Feb 2020 12:21:03 +1300    

Commit 74618e77 added a new check intended to fix a bug, but put  
it in the wrong place so that parallel btree build was always  
disabled.  Do the check after we've actually tried to create  
a DSM segment.  Back-patch to 11, like the earlier commit.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzmDABkJzrNnvf%2BOULK-_A_j9gkYg_Dz-H62jzNv4eKQTw%40mail.gmail.com  

commit   : 7d91b604d9b5d6ec8c19c57a9ffd2f27129cdd94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Feb 2020 13:07:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Feb 2020 13:07:13 -0500    

Commit 499be013d added this field in a rather poorly-thought-through  
manner, with the result being that rather than being a field of the  
Append or MergeAppend plan node as intended (and as it seems to be,  
in text format), it was actually an element of the "Plans" subgroup.  
At least in JSON format, that's flat out invalid syntax, because  
"Plans" is an array not an object.  
  
While it's not hard to move the generation of the field so that it  
appears where it's supposed to, this does result in a visible change  
in field order in text format, in cases where a Append or MergeAppend  
plan node has any InitPlans attached.  That's slightly annoying to  
do in stable branches; but the alternative of continuing to emit  
broken non-text formats seems worse.  
  
Also, since the set of fields emitted is not supposed to be  
data-dependent in non-text formats, make sure that "Subplans Removed"  
appears in Append and MergeAppend nodes even when it's zero, in those  
formats.  (The previous coding made it look like it could appear in  
some other node types such as BitmapAnd, but we don't actually support  
runtime pruning there, so don't emit it in those cases.)  
  
Per bug #16171 from Mahadevan Ramachandran.  Fix by Daniel Gustafsson  
and Tom Lane, reviewed by Hamid Akhtar.  Back-patch to v11 where this  
code came in.  
  
Discussion: https://postgr.es/m/16171-b72259ab75505fa2@postgresql.org  

commit   : 177be9edf4bb966400db7769d61e479aa0fe0201    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Feb 2020 13:56:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Feb 2020 13:56:04 +0900    

First, this code did not bother checking for a failure when calling  
dup().  Then, per zlib, gzerror() returns NULL for a NULL input, which  
can happen if passing down to gzdopen() an invalid file descriptor or if  
there was an allocation failure.  
  
No back-patch is done as this would unlikely be a problem in the field.  
  
Per Coverity.  
  
Reported-by: Tom Lane  

commit   : 1c7a0b387d18c517d45e2f6ec7d8b7d1b2d5fe13    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Feb 2020 18:59:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Feb 2020 18:59:12 -0300    

When replica identity is FULL (an admittedly unusual case), the loop  
that searches for tuples in execReplication.c didn't stop scanning the  
table when once a matching tuple was found.  Add the missing 'break'.  
  
Note slight behavior change: we now return the first matching tuple  
rather than the last one.  They are supposed to be indistinguishable  
anyway, so this shouldn't matter.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/379743f6-ae91-b866-f7a2-5624e6d2b0a4@postgrespro.ru  

commit   : f1f10a1ba9e17e606a7b217ccccdd3cc4d8cb771    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Feb 2020 14:48:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Feb 2020 14:48:42 +0900    

Those new assertions can be used at file scope, outside of any function  
for compilation checks.  This commit provides implementations for C and  
C++, and fallback implementations.  
  
Author: Peter Smith  
Reviewed-by: Andres Freund, Kyotaro Horiguchi, Dagfinn Ilmari Mannsåker,  
Michael Paquier  
Discussion: https://postgr.es/m/201DD0641B056142AC8C6645EC1B5F62014B8E8030@SYD1217  

commit   : 6148e2b9a6399b77e10e277c32d701b84703820f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Feb 2020 13:09:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Feb 2020 13:09:33 -0500    

The error exits added to initialize_SSL() failed to clean up the  
partially-built SSL_context, and some of them also leaked the  
result of SSLerrmessage().  Make them match other error-handling  
cases in that function.  
  
The error exits added to connectOptions2() failed to set conn->status  
like every other error exit in that function.  
  
In passing, make the SSL_get_peer_certificate() error exit look more  
like all the other calls of SSLerrmessage().  
  
Oversights in commit ff8ca5fad.  Coverity whined about leakage of the  
SSLerrmessage() results; I noted the rest in manual code review.  

commit   : 1fd687a035558238c0e3cab09fc22dc61a088869    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 1 Feb 2020 21:57:14 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 1 Feb 2020 21:57:14 +0000    

Using a lookup table of digit pairs reduces the number of divisions  
needed, and calculating the length upfront saves some work; these  
ideas are taken from the code previously committed for floats.  
  
David Fetter, reviewed by Kyotaro Horiguchi, Tels, and me.  
  
Discussion: https://postgr.es/m/20190924052620.GP31596%40fetter.org  

commit   : 7bae0ad9fcb76b28410571dc71edfdc3175c4a02    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Feb 2020 18:30:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Feb 2020 18:30:25 +0900    

Similarly to pg_upgrade, pg_ctl and initdb, a root user is able to use  
--version and --help, but cannot execute the actual operation to avoid  
the creation of files with permissions incompatible with the  
postmaster.  
  
This is a behavior change, so not back-patching is done.  
  
Author: Ian Barwick  
Discussion: https://postgr.es/m/CABvVfJVqOdD2neLkYdygdOHvbWz_5K_iWiqY+psMfA=FeAa3qQ@mail.gmail.com  

commit   : 93745f1e019543fe7b742d0c5e971aad8d08fd56    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Feb 2020 14:29:13 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Feb 2020 14:29:13 +1300    

If we attempt to create a DSM segment when no slots are available,  
we should return the memory to the operating system.  Previously  
we did that if the DSM_CREATE_NULL_IF_MAXSEGMENTS flag was  
passed in, but we didn't do it if an error was raised.  Repair.  
  
Back-patch to 9.4, where DSM segments arrived.  
  
Author: Thomas Munro  
Reviewed-by: Robert Haas  
Reported-by: Julian Backes  
Discussion: https://postgr.es/m/CA%2BhUKGKAAoEw-R4om0d2YM4eqT1eGEi6%3DQot-3ceDR-SLiWVDw%40mail.gmail.com  

commit   : 870ad6a59bbbd95c2dc3cfe67b07d0e079599edf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 17:26:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 17:26:40 -0500    

This code would accept "strinX", where X is any 1-byte character,  
as meaning "string".  Clearly it wasn't meant to do that.  
  
No back-patch, since this doesn't affect correct queries and  
there's some tiny chance we'd break somebody's incorrect query  
in a minor release.  
  
Report and patch by Dominik Czarnota.  
  
Discussion: https://postgr.es/m/CABEVAa1dU0mDCAfaT8WF2adVXTDsLVJy_izotg6ze_hh-cn8qQ@mail.gmail.com  

commit   : 74b35eb468dcf353e25afd4acfc7ee2b2022d6b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 17:03:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 17:03:55 -0500    

Commit fc7695891 changed CheckAttributeType to recurse into ranges,  
but made it pass down the wrong collation (always InvalidOid, since  
ranges as such have no collation).  This would result in guaranteed  
failure when considering a range type whose subtype is collatable.  
  
Embarrassingly, we lack any regression tests that would expose such  
a problem (but fortunately, somebody noticed before we shipped this  
bug in any release).  
  
Fix it to pass down the range's subtype collation property instead,  
and add some regression test cases to exercise collatable-subtype  
ranges a bit more.  Back-patch to all supported branches, as the  
previous patch was.  
  
Report and patch by Julien Rouhaud, test cases tweaked by me  
  
Discussion: https://postgr.es/m/CAOBaU_aBWqNweiGUFX0guzBKkcfJ8mnnyyGC_KBQmO12Mj5f_A@mail.gmail.com  

commit   : 2425f8f714a15fa0fa6fa2f656ad546cbb78e2d6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 14:41:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jan 2020 14:41:49 -0500    

If we failed to fork a worker process, or create a communication pipe  
for one, WaitForTerminatingWorkers would suffer an assertion failure  
if assert-enabled, otherwise crash or go into an infinite loop.  This  
was a consequence of not accounting for the startup condition where  
we've not yet forked all the workers.  
  
The original bug was that ParallelBackupStart would set workerStatus to  
WRKR_IDLE before it had successfully forked a worker.  I made things  
worse in commit b7b8cc0cf by not understanding the undocumented fact  
that the WRKR_TERMINATED state was also meant to represent the case  
where a worker hadn't been started yet: I changed enum T_WorkerStatus  
so that *all* the worker slots were initially in WRKR_IDLE state.  But  
this wasn't any more broken in practice, since even one slot in the  
wrong state would keep WaitForTerminatingWorkers from terminating.  
  
In v10 and later, introduce an explicit T_WorkerStatus value for  
worker-not-started, in hopes of preventing future oversights of the  
same ilk.  Before that, just document that WRKR_TERMINATED is supposed  
to cover that case (partly because it wasn't actively broken, and  
partly because the enum is exposed outside parallel.c in those branches,  
so there's microscopically more risk involved in changing it).  
In all branches, introduce a WORKER_IS_RUNNING status test macro  
to hide which T_WorkerStatus values mean that, and be more careful  
not to access ParallelSlot fields till we're sure they're valid.  
  
Per report from Vignesh C, though this is my patch not his.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CALDaNm1Luv-E3sarR+-unz-BjchquHHyfP+YC+2FS2pt_J+wxg@mail.gmail.com  

commit   : a9cff89f7e638c060621a62ca35da97a12adde42    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 31 Jan 2020 16:26:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 31 Jan 2020 16:26:12 +0100    

We have code paths for Unix socket support and no Unix socket support.  
Now add a third variant: Unix socket support but do not use a Unix  
socket by default in the client or the server, only if you explicitly  
specify one.  This will be useful when we enable Unix socket support  
on Windows.  
  
To implement this, tweak things so that setting DEFAULT_PGSOCKET_DIR  
to "" has the desired effect.  This mostly already worked like that;  
only a few places needed to be adjusted.  Notably, the reference to  
DEFAULT_PGSOCKET_DIR in UNIXSOCK_PATH() could be removed because all  
callers already resolve an empty socket directory setting with a  
default if appropriate.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/75f72249-8ae6-322a-63df-4fe03eeccb9f@2ndquadrant.com  

commit   : 7c23bfd25c423b4513a16d41c5e4d09c32807155    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 31 Jan 2020 11:50:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 31 Jan 2020 11:50:32 +0100    

This might help clarify the API a bit.  

commit   : 7ca8c9706a5785feef5d5eff0078c5361694b274    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2020 13:57:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2020 13:57:56 +0900    

Oversight in commit b0afdca.  

commit   : ef02fb15a35ab7bd74a79afebf35572ed82b5e9f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 17:21:47 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 17:21:47 +1300    

When allocating DSM segments with posix_fallocate() on Linux (see commit  
899bd785), report this activity as a wait event exactly as we would if  
we were using file-backed DSM rather than shm_open()-backed DSM.  
  
Author: Thomas Munro  
Discussion: https://postgr.es/m/CA%2BhUKGKCSh4GARZrJrQZwqs5SYp0xDMRr9Bvb%2BHQzJKvRgL6ZA%40mail.gmail.com  

commit   : d061ea21fc1cc1c657bb5c742f5c4a1564e82ee2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 16:58:38 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 16:58:38 +1300    

When running a lot of large parallel queries concurrently, or a plan with  
a lot of separate Gather nodes, it is possible to run out of DSM slots.  
There are better solutions to these problems requiring architectural  
redesign work, but for now, let's adjust the constants so that it's more  
difficult to hit the limit.  
  
1.  Previously, a DSA area would create up to four segments at each size  
before doubling the size.  After this commit, it will create only two at  
each size, so it ramps up faster and therefore needs fewer slots.  
  
2.  Previously, the total limit on DSM slots allowed for 2 per connection.  
Switch to 5 per connection.  
  
Also remove an obsolete nearby comment.  
  
Author: Thomas Munro  
Reviewed-by: Robert Haas, Andres Freund  
Discussion: https://postre.es/m/CA%2BhUKGL6H2BpGbiF7Lj6QiTjTGyTLW_vLR%3DSn2tEBeTcYXiMKw%40mail.gmail.com  

commit   : a069218163704c44a8996e7e98e765c56e2b9c8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2020 18:25:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2020 18:25:55 -0500    

Very recent gcc complains that PLyObject_ToJsonbValue could return  
a pointer to a local variable.  I think it's wrong; but the coding  
is fragile enough, and the savings of one palloc() minimal enough,  
that it seems better to just do a palloc() all the time.  (My other  
idea of tweaking the if-condition doesn't suppress the warning.)  
  
Back-patch to v11 where this code was introduced.  
  
Discussion: https://postgr.es/m/21547.1580170366@sss.pgh.pa.us  

commit   : 74618e77b43cfce670b4725d5b9a300a2afd12d1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 10:25:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jan 2020 10:25:34 +1300    

If no DSM slots are available, a ParallelContext can still be  
created, but its seg pointer is NULL.  Teach parallel btree build  
to cope with that by falling back to a regular non-parallel build,  
to avoid crashing with a segmentation fault.  
  
Back-patch to 11, where parallel CREATE INDEX landed.  
  
Reported-by: Nicola Contu  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CA%2BhUKGJgJEBnkuODBVomyK3MWFvDBbMVj%3Dgdt6DnRPU-5sQ6UQ%40mail.gmail.com  

commit   : c9d29775195922136c09cc980bb1b7091bf3d859    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jan 2020 13:42:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jan 2020 13:42:14 -0300    

We used to strategically place newlines after some function call left  
parentheses to make pgindent move the argument list a few chars to the  
left, so that the whole line would fit under 80 chars.  However,  
pgindent no longer does that, so the newlines just made the code  
vertically longer for no reason.  Remove those newlines, and reflow some  
of those lines for some extra naturality.  
  
Reviewed-by: Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql  

commit   : 4e89c79a52f8a898edd648b56a00f0f4f840cfe7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jan 2020 13:32:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jan 2020 13:32:04 -0300    

Cosmetic cleanup, not worth backpatching.  
  
Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql  
Reviewed-by: Tom Lane, Michael Paquier  

commit   : 2520cf8c2a0a1d679094dffbd99871884e620ed5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2020 10:51:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2020 10:51:31 -0500    

Per buildfarm.  

commit   : e6f1e560e4c6e764080af8c8d5e76cdea4d8d00a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 31 Jan 2020 00:42:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 31 Jan 2020 00:42:06 +0900    

Previously, TRUNCATE command through a parent table checked the  
permissions on not only the parent table but also the children tables  
inherited from it. This was a bug and inherited queries should perform  
access permission checks on the parent table only. This commit fixes  
that bug.  
  
Back-patch to all supported branches.  
  
Author: Amit Langote  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAHGQGwFHdSvifhJE+-GSNqUHSfbiKxaeQQ7HGcYz6SC2n_oDcg@mail.gmail.com  

commit   : b0afdcad21fde1470e6502a376bfaf0e10d384fa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jan 2020 11:14:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jan 2020 11:14:02 +0900    

Advancing a physical replication slot with pg_replication_slot_advance()  
did not mark the slot as dirty if any advancing was done, preventing the  
follow-up checkpoint to flush the slot data to disk.  This caused the  
advancing to be lost even on clean restarts.  This does not happen for  
logical slots as any advancing marked the slot as dirty.  Per  
discussion, the original feature has been implemented so as in the event  
of a crash the slot may move backwards to a past LSN.  This property is  
kept and more documentation is added about that.  
  
This commit adds some new TAP tests to check the persistency of physical  
and logical slots after advancing across clean restarts.  
  
Author: Alexey Kondratov, Michael Paquier  
Reviewed-by: Andres Freund, Kyotaro Horiguchi, Craig Ringer  
Discussion: https://postgr.es/m/059cc53a-8b14-653a-a24d-5f867503b0ee@postgrespro.ru  
Backpatch-through: 11  

commit   : 26a81bb8152bd9f29bc24c1edfc00e2cbcd68548    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 19:13:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 19:13:34 -0500    

As of commit 50fc694e4, the plperl tests don't want preinstalled  
plperl languages; they now install those themselves.  I'd removed the  
--load-extension options from the GNUmakefile, but missed teaching  
the MSVC build script about that.  
  
Per buildfarm.  

commit   : 50fc694e43742ce3d04a5e9f708432cb022c5f0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 18:42:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 18:42:43 -0500    

This patch creates a new extension property, "trusted".  An extension  
that's marked that way in its control file can be installed by a  
non-superuser who has the CREATE privilege on the current database,  
even if the extension contains objects that normally would have to be  
created by a superuser.  The objects within the extension will (by  
default) be owned by the bootstrap superuser, but the extension itself  
will be owned by the calling user.  This allows replicating the old  
behavior around trusted procedural languages, without all the  
special-case logic in CREATE LANGUAGE.  We have, however, chosen to  
loosen the rules slightly: formerly, only a database owner could take  
advantage of the special case that allowed installation of a trusted  
language, but now anyone who has CREATE privilege can do so.  
  
Having done that, we can delete the pg_pltemplate catalog, moving the  
knowledge it contained into the extension script files for the various  
PLs.  This ends up being no change at all for the in-core PLs, but it is  
a large step forward for external PLs: they can now have the same ease  
of installation as core PLs do.  The old "trusted PL" behavior was only  
available to PLs that had entries in pg_pltemplate, but now any  
extension can be marked trusted if appropriate.  
  
This also removes one of the stumbling blocks for our Python 2 -> 3  
migration, since the association of "plpythonu" with Python 2 is no  
longer hard-wired into pg_pltemplate's initial contents.  Exactly where  
we go from here on that front remains to be settled, but one problem  
is fixed.  
  
Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.  
  
Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us  

commit   : 166ab9c8d343b51e6838d7b59194d32a0019242f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 11:06:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2020 11:06:59 -0500    

Copy the rules that src/test/regress/GNUmakefile uses for this purpose.  
Since these files are .gitignore'd, the mistake wasn't obvious unless  
you happened to look at "git status --ignored" in an allegedly clean  
tree.  
  
Oversight in commit 1858b105b.  No need for back-patch since that's  
not in the back branches.  

commit   : 006b9dcad41956f180f9363648206fede8417592    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jan 2020 10:50:17 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jan 2020 10:50:17 -0500    

My recent commit beb4699091e9fab1c5f465056bef35c9ddf7f9fc caused  
some buildfarm breakage, as reported by Tom Lane. Try to repair.  
  
This fix is extracted from a larger patch by Andrew Dunstan.  
  
Discussion: http://postgr.es/m/8440ddc9-8347-ca64-1405-845d10e054cd@2ndQuadrant.com  
Discussion: http://postgr.es/m/14178.1580312751@sss.pgh.pa.us  

commit   : beb4699091e9fab1c5f465056bef35c9ddf7f9fc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jan 2020 10:19:24 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jan 2020 10:19:24 -0500    

To make this work, (1) makeJsonLexContextCstringLen now takes the  
encoding to be used as an argument; (2) check_stack_depth() is made to  
do nothing in frontend code, and (3) elog(ERROR, ...) is changed to  
pg_log_fatal + exit in frontend code.  
  
Mark Dilger, reviewed and slightly revised by me.  
  
Discussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com  

commit   : dc788668bb269b10a108e87d14fefd1b9301b793    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 29 Jan 2020 15:43:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 29 Jan 2020 15:43:32 +0100    

Before, if a recovery target is configured, but the archive ended  
before the target was reached, recovery would end and the server would  
promote without further notice.  That was deemed to be pretty wrong.  
With this change, if the recovery target is not reached, it is a fatal  
error.  
  
Based-on-patch-by: Leif Gunnar Erlandsen <leif@lako.no>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/993736dd3f1713ec1f63fc3b653839f5@lako.no  

commit   : 29e321cdd63ea48fd0223447d58f4742ad729eb0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Jan 2020 15:08:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Jan 2020 15:08:19 +0900    

channel_binding's longest allowed value is not "7", it is actually "8".  
gssencmode also got that wrong.  
  
A similar mistake has been fixed as of f4051e3.  
  
Backpatch down to v12, where gssencmode has been introduced.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz  
Backpatch-through: 12  

commit   : 47bc9ced0d0e96523e2c639c7066c9aede189ed7    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 29 Jan 2020 11:08:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 29 Jan 2020 11:08:50 +0530    

Commit 40d964ec99 allowed vacuum command to leverage multiple CPUs by  
invoking parallel workers to process indexes.  This commit provides a  
'--parallel' option to specify the parallel degree used by vacuum command.  
  
Author: Masahiko Sawada, with few modifications by me  
Reviewed-by: Mahendra Singh and Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com  

commit   : 01d9676a53af075feb42d2f83ddb8c61186812fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jan 2020 17:26:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jan 2020 17:26:37 -0500    

EvalPlanQualStart() supposed that it could re-use the relsubs_rowmark  
and relsubs_done arrays from a prior instantiation.  But since they are  
allocated in the es_query_cxt of the recheckestate, that's just wrong;  
EvalPlanQualEnd() will blow away that storage.  Therefore we were using  
storage that could have been reallocated to something else, causing all  
sorts of havoc.  
  
I think this was modeled on the old code's handling of es_epqTupleSlot,  
but since the code was anyway clearing the arrays at re-use, there's  
clearly no expectation of importing any outside state.  So it's just  
a dubious savings of a couple of pallocs, which is negligible compared  
to setting up a new planstate tree.  Therefore, just allocate the  
arrays always.  (I moved the allocations slightly for readability.)  
  
In principle this bug could cause a problem whenever EPQ rechecks are  
needed in more than one target table of a ModifyTable plan node.  
In practice it seems not quite so easy to trigger as that; I couldn't  
readily duplicate a crash with a partitioned target table, for instance.  
That's probably down to incidental choices about when to free or  
reallocate stuff.  The added isolation test case does seem to reliably  
show an assertion failure, though.  
  
Per report from Oleksii Kliukin.  Back-patch to v12 where the bug was  
introduced (evidently by commit 3fb307bc4).  
  
Discussion: https://postgr.es/m/EEF05F66-2871-4786-992B-5F45C92FEE2E@hintbits.com  

commit   : 30012a04a6c8127397a8ab71e160d9c7e7fbe874    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Jan 2020 12:55:30 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Jan 2020 12:55:30 +0200    

Commit 38a957316d got this backwards.  
  
Author: Kyotaro Horiguchi  
Discussion: https://www.postgresql.org/message-id/20200128.194408.2260703306774646445.horikyota.ntt@gmail.com  

commit   : 11da6bccd178c1e0d5b0fbc4bccc538f8a005dd3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 20:30:40 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 20:30:40 +1300    

Per build farm animal anole, after commit 6f38d4dac3.  

commit   : 78aaa0e82335527b8cc91601c98c9abbbc3ef3ee    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 15:28:36 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 15:28:36 +1300    

It's not OK to do that without calling CHECK_FOR_INTERRUPTS().  
Let the next wait loop deal with it, following the usual pattern.  
  
One consequence of this bug was that a SIGTERM delivered in a very  
narrow timing window could leave a parallel worker process waiting  
forever for a condition variable that will never be signaled, after  
an error was raised in other process.  
  
The code is a bit different in the stable branches due to commit  
1321509f, making problems less likely there.  No back-patch for now,  
but we may finish up deciding to make a similar change after more  
discussion.  
  
Author: Thomas Munro  
Reviewed-by: Shawn Debnath  
Reported-by: Tomas Vondra  
Discussion: https://postgr.es/m/CA%2BhUKGJOm8zZHjVA8svoNT3tHY0XdqmaC_kHitmgXDQM49m1dA%40mail.gmail.com  

commit   : 05f18c6b6b6e4b44302ee20a042cedc664532aa2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 28 Jan 2020 07:48:10 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 28 Jan 2020 07:48:10 +0530    

This gives more information to the user about the error and it makes such  
messages consistent with the other similar messages in the code.  
  
Reported-by: Simon Riggs  
Author: Mahendra Singh and Simon Riggs  
Reviewed-by: Beena Emerson and Amit Kapila  
Discussion: https://postgr.es/m/CANP8+j+7YUvQvGxTrCiw77R23enMJ7DFmyA3buR+fa2pKs4XhA@mail.gmail.com  

commit   : ff8ca5fadd819155c82bd16fcc6b7231af649cf8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jan 2020 10:40:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jan 2020 10:40:48 +0900    

These two new parameters, named sslminprotocolversion and  
sslmaxprotocolversion, allow to respectively control the minimum and the  
maximum version of the SSL protocol used for the SSL connection attempt.  
The default setting is to allow any version for both the minimum and the  
maximum bounds, causing libpq to rely on the bounds set by the backend  
when negotiating the protocol to use for an SSL connection.  The bounds  
are checked when the values are set at the earliest stage possible as  
this makes the checks independent of any SSL implementation.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier, Cary Huang  
Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se  

commit   : 6f38d4dac381b5b8bead302a0b4f81761042cd25    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 13:13:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 28 Jan 2020 13:13:04 +1300    

The following changes make the predicate locking functions more  
generic and suitable for use by future access methods:  
  
- PredicateLockTuple() is renamed to PredicateLockTID().  It takes  
  ItemPointer and inserting transaction ID instead of HeapTuple.  
  
- CheckForSerializableConflictIn() takes blocknum instead of buffer.  
  
- CheckForSerializableConflictOut() no longer takes HeapTuple or buffer.  
  
Author: Ashwin Agrawal  
Reviewed-by: Andres Freund, Kuntal Ghosh, Thomas Munro  
Discussion: https://postgr.es/m/CALfoeiv0k3hkEb3Oqk%3DziWqtyk2Jys1UOK5hwRBNeANT_yX%2Bng%40mail.gmail.com  

commit   : 4589c6a2a30faba53d0655a8e3a29b54d28bb6f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jan 2020 18:46:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jan 2020 18:46:30 -0500    

In the wake of 1f3a02173, assorted buildfarm members were warning about  
"control reaches end of non-void function" or the like.  Do what we've  
done elsewhere: in place of a "default" switch case that will prevent  
the compiler from warning about unhandled enum values, put a catchall  
elog() after the switch.  And return a dummy value to satisfy compilers  
that don't know elog() doesn't return.  

commit   : 73ce2a03f30b52d6bfb26bc28f1e3e1aa1637577    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jan 2020 11:22:13 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jan 2020 11:22:13 -0500    

Specifically, move those functions that depend on ereport()  
from jsonapi.c to jsonfuncs.c, in preparation for allowing  
jsonapi.c to be used from frontend code.  
  
A few cases where elog(ERROR, ...) is used for can't-happen  
conditions are left alone; we can handle those in some other  
way in frontend code.  
  
Reviewed by Mark Dilger and Andrew Dunstan.  
  
Discussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com  

commit   : 1f3a021730be98b880d94cabbe21de7e4d8136f5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jan 2020 11:03:21 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jan 2020 11:03:21 -0500    

Instead, it now returns a value indicating either success or the  
type of error which occurred. The old behavior is still available  
by calling pg_parse_json_or_ereport(). If the new interface is  
used, an error can be thrown by passing the return value of  
pg_parse_json() to json_ereport_error().  
  
pg_parse_json() can still elog() in can't-happen cases, but it  
seems like that issue is best handled separately.  
  
Adjust json_lex() and json_count_array_elements() to return an  
error code, too.  
  
This is all in preparation for making the backend's json parser  
available to frontend code.  
  
Reviewed and/or tested by Mark Dilger and Andrew Dunstan.  
  
Discussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com  

commit   : 3e4818e9dd5be294d97ca67012528cb1c0b0ccaa    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Jan 2020 12:52:08 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Jan 2020 12:52:08 +1300    

Currently, Parallel Hash Join cannot be used for full/right joins,  
so there is no point in setting the match flag.  It turns out that  
the cache coherence traffic generated by those writes slows down  
large systems running many-core joins, so let's stop doing that.  
In future, if we need to use match bits in parallel joins, we might  
want to consider setting them only if not already set.  
  
Back-patch to 11, where Parallel Hash Join arrived.  
  
Reported-by: Deng, Gang  
Discussion: https://postgr.es/m/0F44E799048C4849BAE4B91012DB910462E9897A%40SHSMSX103.ccr.corp.intel.com  

commit   : 10a525230fb18331dbcfd6a4a7248d76f55c331c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jan 2020 11:02:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jan 2020 11:02:05 +0900    

The leaks have been detected by a Coverity run on Windows.  No backpatch  
is done as the leaks are minor.  
  
While on it, make restricted token creation more consistent in its error  
handling by logging an error instead of a warning if missing  
advapi32.dll, which was missing in the NT4 days.  Any modern platform  
should have this DLL around.  Now, if the library is not there, an error  
is still reported back to the caller, and nothing is done do there is no  
behavior change done in this commit.  
  
Author: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQApa9MG0foPkgPX87fipk=vhnF2Xfg+CfUyR08h4R7Mywg@mail.gmail.com  

commit   : 3ec20c7091e97a554e7447ac2b7f4ed795631395    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jan 2020 16:31:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jan 2020 16:31:48 -0500    

In non-TEXT output formats, the "Settings" field should appear when  
requested, even if it would be empty.  
  
Also, get rid of the premature optimization of counting all the  
GUC_EXPLAIN variables at startup.  Since there was no provision for  
adjusting that count later, all it'd take would be some extension marking  
a parameter as GUC_EXPLAIN to risk an assertion failure or memory stomp.  
We could make get_explain_guc_options() count those variables on-the-fly,  
or dynamically resize its array ... but TBH I do not think that making a  
transient array of pointers a bit smaller is worth any extra complication,  
especially when you consider all the other transient space EXPLAIN eats.  
So just allocate that array at the max possible size.  
  
In HEAD, also add some regression test coverage for this feature.  
  
Because of the memory-stomp hazard, back-patch to v12 where this  
feature was added.  
  
Discussion: https://postgr.es/m/19416.1580069629@sss.pgh.pa.us  

commit   : f37ff03478aefb5e01d748b85ad86e6213624992    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Jan 2020 09:05:27 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Jan 2020 09:05:27 +1300    

As reported independently by a couple of people, _mdfd_openseg() is coded in a  
way that seems to imply that the segments could be opened in an order that  
isn't strictly sequential.  Even if that were true, it's also using the wrong  
comparison.  It's not an active bug, since the condition is always true anyway,  
but it's confusing, so replace it with an assertion.  
  
Author: Thomas Munro  
Reviewed-by: Andres Freund, Kyotaro Horiguchi, Noah Misch  
Discussion: https://postgr.es/m/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3DcqO5DAybk6KnHKzgGvxhxA%40mail.gmail.com  
Discussion: https://postgr.es/m/20191222091930.GA1280238%40rfd.leadboat.com  

commit   : 215824f9188a2b19f870e6a707c5a81e1ac3f1fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jan 2020 14:31:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jan 2020 14:31:08 -0500    

In a statement like "UPDATE remote_tab SET (x,y) = (SELECT ...)",  
we'd conclude that the statement could be directly executed remotely,  
because the sub-SELECT is in a resjunk tlist item that's not examined  
for shippability.  Currently that ends up crashing if the sub-SELECT  
contains any remote Vars.  Prevent the crash by deeming MULTIEXEC  
Params to be unshippable.  
  
This is a bit of a brute-force solution, since if the sub-SELECT  
*doesn't* contain any remote Vars, the current execution technology  
would work; but that's not a terribly common use-case for this syntax,  
I think.  In any case, we generally don't try to ship sub-SELECTs, so  
it won't surprise anybody that this doesn't end up as a remote direct  
update.  I'd be inclined to see if that general limitation can be fixed  
before worrying about this case further.  
  
Per report from Lukáš Sobotka.  
  
Back-patch to 9.6.  9.5 had MULTIEXPR, but we didn't try to perform  
remote direct updates then, so the case didn't arise anyway.  
  
Discussion: https://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com  

commit   : 38a957316d7e46d4b00de40f43966984a463d80a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 26 Jan 2020 11:39:00 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 26 Jan 2020 11:39:00 +0200    

The signature of XLogReadRecord() required the caller to pass the starting  
WAL position as argument, or InvalidXLogRecPtr to continue reading at the  
end of previous record. That's slightly awkward to the callers, as most  
of them don't want to randomly jump around in the WAL stream, but start  
reading at one position and then read everything from that point onwards.  
Remove the 'RecPtr' argument and add a new function XLogBeginRead() to  
specify the starting position instead. That's more convenient for the  
callers. Also, xlogreader holds state that is reset when you change the  
starting position, so having a separate function for doing that feels like  
a more natural fit.  
  
This changes XLogFindNextRecord() function so that it doesn't reset the  
xlogreader's state to what it was before the call anymore. Instead, it  
positions the xlogreader to the found record, like XLogBeginRead().  
  
Reviewed-by: Kyotaro Horiguchi, Alvaro Herrera  
Discussion: https://www.postgresql.org/message-id/5382a7a3-debe-be31-c860-cb810c08f366%40iki.fi  

commit   : 10013684970453a0ddc86050bba813c611114321    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jan 2020 18:16:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jan 2020 18:16:42 -0500    

Previously, it was possible for EXPLAIN ANALYZE of a parallel query  
to produce several different "Workers" fields for a single plan node,  
because different portions of explain.c independently generated  
per-worker data and wrapped that output in separate fields.  This  
is pretty bogus, especially for the structured output formats: even  
if it's not technically illegal, most programs would have a hard time  
dealing with such data.  
  
To improve matters, add infrastructure that allows redirecting  
per-worker values into a side data structure, and then collect that  
data into a single "Workers" field after we've finished running all  
the relevant code for a given plan node.  
  
There are a few visible side-effects:  
  
* In text format, instead of something like  
  
  Sort Method: external merge  Disk: 4920kB  
  Worker 0:  Sort Method: external merge  Disk: 5880kB  
  Worker 1:  Sort Method: external merge  Disk: 5920kB  
  Buffers: shared hit=682 read=10188, temp read=1415 written=2101  
  Worker 0:  actual time=130.058..130.324 rows=1324 loops=1  
    Buffers: shared hit=337 read=3489, temp read=505 written=739  
  Worker 1:  actual time=130.273..130.512 rows=1297 loops=1  
    Buffers: shared hit=345 read=3507, temp read=505 written=744  
  
you get  
  
  Sort Method: external merge  Disk: 4920kB  
  Buffers: shared hit=682 read=10188, temp read=1415 written=2101  
  Worker 0:  actual time=130.058..130.324 rows=1324 loops=1  
    Sort Method: external merge  Disk: 5880kB  
    Buffers: shared hit=337 read=3489, temp read=505 written=739  
  Worker 1:  actual time=130.273..130.512 rows=1297 loops=1  
    Sort Method: external merge  Disk: 5920kB  
    Buffers: shared hit=345 read=3507, temp read=505 written=744  
  
* When JIT is enabled, any relevant per-worker JIT stats are attached  
to the child node of the Gather or Gather Merge node, which is where  
the other per-worker output has always been.  Previously, that info  
was attached directly to a Gather node, or missed entirely for Gather  
Merge.  
  
* A query's summary JIT data no longer includes a bogus  
"Worker Number: -1" field.  
  
A notable code-level change is that indenting for lines of text-format  
output should now be handled by calling "ExplainIndentText(es)",  
instead of hard-wiring how much space to emit.  This seems a good deal  
cleaner anyway.  
  
This patch also adds a new "explain.sql" regression test script that's  
dedicated to testing EXPLAIN.  There is more that can be done in that  
line, certainly, but for now it just adds some coverage of the XML and  
YAML output formats, which had been completely untested.  
  
Although this is surely a bug fix, it's not clear that people would  
be happy with rearranging EXPLAIN output in a minor release, so apply  
to HEAD only.  
  
Maciek Sakrejda and Tom Lane, based on an idea of Andres Freund's;  
reviewed by Georgios Kokolatos  
  
Discussion: https://postgr.es/m/CAOtHd0AvAA8CLB9Xz0wnxu1U=zJCKrr1r4QwwXi_kcQsHDVU=Q@mail.gmail.com  

commit   : 13661ddd7eaec7e2809ff5c29fc14653b6161036    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Jan 2020 14:00:59 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Jan 2020 14:00:59 +0000    

These compute the greatest common divisor and least common multiple of  
a pair of numbers using the Euclidean algorithm.  
  
Vik Fearing, reviewed by Fabien Coelho.  
  
Discussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com  

commit   : 530609aa4263bee5b5ca205d83f0dbad098d0465    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:41 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:41 -0500    

At first glance, this function seems useful, but it actually increases  
the amount of code required rather than decreasing it. Inline the  
logic into the callers instead; most callers don't use the 'lexeme'  
argument for anything and as a result considerable simplification is  
possible.  
  
Along the way, fix the header comment for the nearby function  
lex_expect(), which mislabeled it as lex_accept().  
  
Patch by me, reviewed by David Steele, Mark Dilger, and Andrew  
Dunstan.  
  
Discussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com  

commit   : 11b5e3e35d3900164cb36754ee4e4dcab0bd02f0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jan 2020 10:17:43 -0800    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jan 2020 10:17:43 -0800    

Keep the code that pertains to the 'json' data type in json.c, but  
move the lexing and parsing code to a new file jsonapi.c, a name  
I chose because the corresponding prototypes are in jsonapi.h.  
  
This seems like a logical division, because the JSON lexer and parser  
are also used by the 'jsonb' data type, but the SQL-callable functions  
in json.c are a separate thing. Also, the new jsonapi.c file needs to  
include far fewer header files than json.c, which seems like a good  
sign that this is an appropriate place to insert an abstraction  
boundary. I took the opportunity to remove a few apparently-unneeded  
includes from json.c at the same time.  
  
Patch by me, reviewed by David Steele, Mark Dilger, and Andrew  
Dunstan. The previous commit was, too, but I forgot to note it  
in the commit message.  
  
Discussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com  

commit   : ce0425b162d0a8c168e1fbab5324fb1cbca4b6b7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jan 2020 09:58:37 -0800    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jan 2020 09:58:37 -0800    

The major change here is that we no longer include jsonb.h into  
jsonapi.h. The reason that was necessary is that jsonapi.h included  
several prototypes functions in jsonfuncs.c that depend on the Jsonb  
type. Move those prototypes to a new header, jsonfuncs.h, and include  
it where needed.  
  
The other change is that JsonEncodeDateTime is now declared in  
json.h rather than jsonapi.h.  
  
Taken together, these steps eliminate all dependencies of jsonapi.h  
on backend-only data types and header files, so that it can  
potentially be included in frontend code.  

commit   : d694e0bb793ebd6b392e6ef6a3b0a59ae66cbc95    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 24 Jan 2020 20:42:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 24 Jan 2020 20:42:52 +0900    

This function allows us to fsync the specified file or directory.  
It's useful, for example, when we want to sync the file that  
pg_file_write() writes out or that COPY TO exports the data into,  
for durability.  
  
Author: Fujii Masao  
Reviewed-By: Julien Rouhaud, Arthur Zakirov, Michael Paquier, Atsushi Torikoshi  
Discussion: https://www.postgresql.org/message-id/CAHGQGwGY8uzZ_k8dHRoW1zDcy1Z7=5GQ+So4ZkVy2u=nLsk=hA@mail.gmail.com  

commit   : cc25464763f0211e59a209eb50a7b7a79449051f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jan 2020 12:23:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jan 2020 12:23:06 +0100    

src/include/common/unicode_combining_table.h is currently not meant to  
be included standalone.  Things could be refactored to allow it, but  
that would be beyond the present purpose.  So adding an exclusion here  
seems best.  
  
Discussion: https://www.postgresql.org/message-id/10754.1579535012@sss.pgh.pa.us  

commit   : a7a848844d74e63ee102717972de3e60b5f4549a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Jan 2020 10:27:49 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Jan 2020 10:27:49 +0100    

commit   : 6de7bcb76f6593dcd107a6bfed645f2142bf3225    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Jan 2020 09:55:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Jan 2020 09:55:21 +0900    

Only the parameter parallel_workers can be used directly with ALTER  
TABLE.  
  
Issue introduced in 6f3a13f, so backpatch down to 10.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200106025623.GA12066@telsasoft.com  
Backpatch-through: 10  

commit   : c32704441d47cc1cbb36367a429814511edb6ffd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 18:20:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 18:20:57 -0500    

I had supposed that all versions of Readline that have filename  
quoting hooks also have the rl_completion_suppress_quote variable.  
But it seems OpenBSD managed to find a version someplace that does  
not, so we'll have to expend a separate configure probe for that.  
  
(Light testing suggests that this version also lacks the bugs that  
make it necessary to frob that variable.  Hooray!)  
  
Per buildfarm.  

commit   : 9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 16:15:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 16:15:32 -0500    

I had supposed that the from_char_seq_search() call sites were  
all passing the constant arrays you'd expect them to pass ...  
but on looking closer, the one for DY format was passing the  
days[] array not days_short[].  This accidentally worked because  
the day abbreviations in English are all the same as the first  
three letters of the full day names.  However, once we took out  
the "maximum comparison length" logic, it stopped working.  
  
As penance for that oversight, add regression test cases covering  
this, as well as every other switch case in DCH_from_char() that  
was not reached according to the code coverage report.  
  
Also, fold the DCH_RM and DCH_rm cases into one --- now that  
seq_search is case independent, there's no need to pass different  
comparison arrays for those cases.  
  
Back-patch, as the previous commit was.  

commit   : 4c70098ffa8cf19e79e7b124ccac05dd338c937b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 13:42:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 13:42:09 -0500    

seq_search(), which is used to match input substrings to constants  
such as month and day names, had a lot of bizarre and unnecessary  
behaviors.  It was mostly possible to avert our eyes from that before,  
but we don't want to duplicate those behaviors in the upcoming patch  
to allow recognition of non-English month and day names.  So it's time  
to clean this up.  In particular:  
  
* seq_search scribbled on the input string, which is a pretty dangerous  
thing to do, especially in the badly underdocumented way it was done here.  
Fortunately the input string is a temporary copy, but that was being made  
three subroutine levels away, making it something easy to break  
accidentally.  The behavior is externally visible nonetheless, in the form  
of odd case-folding in error reports about unrecognized month/day names.  
The scribbling is evidently being done to save a few calls to pg_tolower,  
but that's such a cheap function (at least for ASCII data) that it's  
pretty pointless to worry about.  In HEAD I switched it to be  
pg_ascii_tolower to ensure it is cheap in all cases; but there are corner  
cases in Turkish where this'd change behavior, so leave it as pg_tolower  
in the back branches.  
  
* seq_search insisted on knowing the case form (all-upper, all-lower,  
or initcap) of the constant strings, so that it didn't have to case-fold  
them to perform case-insensitive comparisons.  This likewise seems like  
excessive micro-optimization, given that pg_tolower is certainly very  
cheap for ASCII data.  It seems unsafe to assume that we know the case  
form that will come out of pg_locale.c for localized month/day names, so  
it's better just to define the comparison rule as "downcase all strings  
before comparing".  (The choice between downcasing and upcasing is  
arbitrary so far as English is concerned, but it might not be in other  
locales, so follow citext's lead here.)  
  
* seq_search also had a parameter that'd cause it to report a match  
after a maximum number of characters, even if the constant string were  
longer than that.  This was not actually used because no caller passed  
a value small enough to cut off a comparison.  Replicating that behavior  
for localized month/day names seems expensive as well as useless, so  
let's get rid of that too.  
  
* from_char_seq_search used the maximum-length parameter to truncate  
the input string in error reports about not finding a matching name.  
This leads to rather confusing reports in many cases.  Worse, it is  
outright dangerous if the input string isn't all-ASCII, because we  
risk truncating the string in the middle of a multibyte character.  
That'd lead either to delivering an illegible error message to the  
client, or to encoding-conversion failures that obscure the actual  
data problem.  Get rid of that in favor of truncating at whitespace  
if any (a suggestion due to Alvaro Herrera).  
  
In addition to fixing these things, I const-ified the input string  
pointers of DCH_from_char and its subroutines, to make sure there  
aren't any other scribbling-on-input problems.  
  
The risk of generating a badly-encoded error message seems like  
enough of a bug to justify back-patching, so patch all supported  
branches.  
  
Discussion: https://postgr.es/m/29432.1579731087@sss.pgh.pa.us  

commit   : cd69ec66c88633c09bc9a984a7f0930e09c7c96e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 11:07:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2020 11:07:12 -0500    

The Readline library contains a fair amount of knowledge about how to  
tab-complete filenames, but it turns out that that doesn't work too well  
unless we follow its expectation that we use its filename quoting hooks  
to quote and de-quote filenames.  We were trying to do such quote handling  
within complete_from_files(), and that's still what we have to do if we're  
using libedit, which lacks those hooks.  But for Readline, it works a lot  
better if we tell Readline that single-quote is a quoting character and  
then provide hooks that know the details of the quoting rules for SQL  
and psql meta-commands.  
  
Hence, resurrect the quoting hook functions that existed in the original  
version of tab-complete.c (and were disabled by commit f6689a328 because  
they "didn't work so well yet"), and whack on them until they do seem to  
work well.  
  
Notably, this fixes bug #16059 from Steven Winfield, who pointed out  
that the previous coding would strip quote marks from filenames in SQL  
COPY commands, even though they're syntactically necessary there.  
Now, we not only don't do that, but we'll add a quote mark when you  
tab-complete, even if you didn't type one.  
  
Getting this to work across a range of libedit versions (and, to a  
lesser extent, libreadline versions) was depressingly difficult.  
It will be interesting to see whether the new regression test cases  
pass everywhere in the buildfarm.  
  
Some future patch might try to handle quoted SQL identifiers with  
similar explicit quoting/dequoting logic, but that's for another day.  
  
Patch by me, reviewed by Peter Eisentraut.  
  
Discussion: https://postgr.es/m/16059-8836946734c02b84@postgresql.org  

commit   : 5ba40b62318e4d941497333b72d589420a48d82f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jan 2020 17:01:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jan 2020 17:01:46 +0900    

The docs had some typos and grammar mistakes, and its indentation was  
inconsistent.  
  
Author: Amit Langote, Justin Pryzby  
Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com  

commit   : f942dfb952aaccb0163564c86c0b7654b8512807    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jan 2020 15:56:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jan 2020 15:56:56 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200113004542.GA26045@telsasoft.com  

commit   : 611ce856f5a862a291a05d148828208e1f4ed46b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 22 Jan 2020 18:35:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 22 Jan 2020 18:35:05 -0300    

This test case was sketched in commit message 4c87010981f3 to explain an  
ancient bug; it translates to a coverage increase, so add it to the BRIN  
regression tests.  

commit   : 41c184bc642b25f67fb1d8ee290f28805fa5a0b4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Jan 2020 11:56:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Jan 2020 11:56:34 +0900    

Detection of WAL records having references to invalid pages  
during recovery causes PostgreSQL to raise a PANIC-level error,  
aborting the recovery. Setting ignore_invalid_pages to on causes  
the system to ignore those WAL records (but still report a warning),  
and continue recovery. This behavior may cause crashes, data loss,  
propagate or hide corruption, or other serious problems.  
However, it may allow you to get past the PANIC-level error,  
to finish the recovery, and to cause the server to start up.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://www.postgresql.org/message-id/CAHGQGwHCK6f77yeZD4MHOnN+PaTf6XiJfEB+Ce7SksSHjeAWtg@mail.gmail.com  

commit   : 79a3efb84d09b1e98ad7bb2756fa570efb578d1d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Jan 2020 07:43:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Jan 2020 07:43:51 +0530    

In commit 40d964ec99, we changed the way memory is allocated for dead  
tuples but forgot to update the place where we compute the maximum  
number of dead tuples.  This could lead to invalid memory requests.  
  
Reported-by: Andres Freund  
Diagnosed-by: Andres Freund  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila and Dilip Kumar  
Discussion: https://postgr.es/m/20200121060020.e3cr7s7fj5rw4lok@alap3.anarazel.de  

commit   : a904abe2e284f570168839e52e18ef0b7f26179d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jan 2020 09:49:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jan 2020 09:49:18 +0900    

Attempting to use CREATE INDEX, DROP INDEX or REINDEX with CONCURRENTLY  
on a temporary relation with ON COMMIT actions triggered unexpected  
errors because those operations use multiple transactions internally to  
complete their work.  Here is for example one confusing error when using  
ON COMMIT DELETE ROWS:  
ERROR:  index "foo" already contains data  
  
Issues related to temporary relations and concurrent indexing are fixed  
in this commit by enforcing the non-concurrent path to be taken for  
temporary relations even if using CONCURRENTLY, transparently to the  
user.  Using a non-concurrent path does not matter in practice as locks  
cannot be taken on a temporary relation by a session different than the  
one owning the relation, and the non-concurrent operation is more  
effective.  
  
The problem exists with REINDEX since v12 with the introduction of  
CONCURRENTLY, and with CREATE/DROP INDEX since CONCURRENTLY exists for  
those commands.  In all supported versions, this caused only confusing  
error messages to be generated.  Note that with REINDEX, it was also  
possible to issue a REINDEX CONCURRENTLY for a temporary relation owned  
by a different session, leading to a server crash.  
  
The idea to enforce transparently the non-concurrent code path for  
temporary relations comes originally from Andres Freund.  
  
Reported-by: Manuel Rigger  
Author: Michael Paquier, Heikki Linnakangas  
Reviewed-by: Andres Freund, Álvaro Herrera, Heikki Linnakangas  
Discussion: https://postgr.es/m/CA+u7OA6gP7YAeCguyseusYcc=uR8+ypjCcgDDCTzjQ+k6S9ksQ@mail.gmail.com  
Backpatch-through: 9.4  

commit   : 9b9c5f279e8261ab90dc64559911d2578288b7e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jan 2020 16:17:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jan 2020 16:17:21 -0500    

The behavior of something like  
  
ALTER TABLE transactions  
  ADD COLUMN status varchar(30) DEFAULT 'old',  
  ALTER COLUMN status SET default 'current';  
  
is to fill existing table rows with 'old', not 'current'.  That's  
intentional and desirable for a couple of reasons:  
  
* It makes the behavior the same whether you merge the sub-commands  
into one ALTER command or give them separately;  
  
* If we applied the new default while filling the table, there would  
be no way to get the existing behavior in one SQL command.  
  
The same reasoning applies in cases that add a column and then  
manipulate its GENERATED/IDENTITY status in a second sub-command,  
since the generation expression is really just a kind of default.  
However, that wasn't very obvious (at least not to me; earlier in  
the referenced discussion thread I'd thought it was a bug to be  
fixed).  And it certainly wasn't documented.  
  
Hence, add documentation, code comments, and a test case to clarify  
that this behavior is all intentional.  
  
In passing, adjust ATExecAddColumn's defaults-related relkind check  
so that it matches up exactly with ATRewriteTables, instead of being  
effectively (though not literally) the negated inverse condition.  
The reasoning can be explained a lot more concisely that way, too  
(not to mention that the comment now matches the code, which it  
did not before).  
  
Discussion: https://postgr.es/m/10365.1558909428@sss.pgh.pa.us  

commit   : affdde2e15d9df6e9736bbb7e7cd9d56049d2f5a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Jan 2020 23:26:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Jan 2020 23:26:51 -0800    

The code checking whether an aggregate transition value needs to be  
reparented into the current context has always only compared the  
transition return value with the previous transition value by datum,  
i.e. without regard for NULLness.  This normally works, because when  
the transition function returns NULL (via fcinfo->isnull), it'll  
return a value that won't be the same as its input value.  
  
But there's no hard requirement that that's the case. And it turns  
out, it's possible to hit this case (see discussion or reproducers),  
leading to a non-null transition value not being reparented, followed  
by a crash caused by that.  
  
Instead of adding another comparison of NULLness, instead have  
ExecAggTransReparent() ensure that pergroup->transValue ends up as 0  
when the new transition value is NULL. That avoids having to add an  
additional branch to the much more common cases of the transition  
function returning the old transition value (which is a pointer in  
this case), and when the new value is different, but not NULL.  
  
In branches since 69c3936a149, also deduplicate the reparenting code  
between the expression evaluation based transitions, and the path for  
ordered aggregates.  
  
Reported-By: Teodor Sigaev, Nikita Glukhov  
Author: Andres Freund  
Discussion: https://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru  
Backpatch: 9.4-, this issue has existed since at least 7.4  

commit   : 62c9b522311afd791fd92fe46a294f7e21f10540    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jan 2020 13:46:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jan 2020 13:46:39 +0900    

This helps integration of extensions with Windows.  The following  
parameters are changed:  
- idle_in_transaction_session_timeout (9.6 and newer versions)  
- lock_timeout  
- statement_timeout  
- track_activities  
- track_counts  
- track_functions  
  
Author: Pascal Legrand  
Reviewed-by: Amit Kamila, Julien Rouhaud, Michael Paquier  
Discussion: https://postgr.es/m/1579298868581-0.post@n3.nabble.com  
Backpatch-through: 9.4  

commit   : 31f403e95fdf88338d3fc9c6af80fcf6d8241044    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 14:26:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 14:26:56 -0500    

Some buildfarm members were still warning about this, because in  
9c679a08f I'd missed decorating one of the ereport() code paths  
with a dummy return.  
  
Also, adjust the error messages to be more in line with project  
style guide.  

commit   : cd23a2019c4b8da47905e91c8a841cadac978a32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 12:57:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 12:57:17 -0500    

sigTermHandler() tried to be careful to invoke only operations that  
are safe to do in a signal handler.  But for some reason we forgot  
that exit(3) is not among those, because it calls atexit handlers  
that might do various random things.  (pg_dump itself installs no  
atexit handlers, but e.g. OpenSSL does.)  That led to crashes or  
lockups when attempting to terminate a parallel dump or restore  
via a signal.  
  
Fix by calling _exit() instead.  
  
Per bug #16199 from Raúl Marín.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org  

commit   : 4c87010981f3a9a41751e5550f6eb889ab5667e8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jan 2020 10:36:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jan 2020 10:36:35 +0200    

The BRIN add_value() and union() functions need to make a longer-lived  
copy of the argument, if they want to store it in the BrinValues struct  
also passed as argument. The functions for the "inclusion operator  
classes" used with box, range and inet types didn't take into account  
that the union helper function might return its argument as is, without  
making a copy. Check for that case, and make a copy if necessary. That  
case arises at least with the range_union() function, when one of the  
arguments is an 'empty' range:  
  
CREATE TABLE brintest (n numrange);  
CREATE INDEX brinidx ON brintest USING brin (n);  
INSERT INTO brintest VALUES ('empty');  
INSERT INTO brintest VALUES (numrange(0, 2^1000::numeric));  
INSERT INTO brintest VALUES ('(-1, 0)');  
  
SELECT brin_desummarize_range('brinidx', 0);  
SELECT brin_summarize_range('brinidx', 0);  
  
Backpatch down to 9.5, where BRIN was introduced.  
  
Discussion: https://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi  
Reviewed-by: Emre Hasegeli, Tom Lane, Alvaro Herrera  

commit   : 40d964ec997f64227bc0ff5e058dc4a5770a70a9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jan 2020 07:57:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jan 2020 07:57:49 +0530    

This feature allows the vacuum to leverage multiple CPUs in order to  
process indexes.  This enables us to perform index vacuuming and index  
cleanup with background workers.  This adds a PARALLEL option to VACUUM  
command where the user can specify the number of workers that can be used  
to perform the command which is limited by the number of indexes on a  
table.  Specifying zero as a number of workers will disable parallelism.  
This option can't be used with the FULL option.  
  
Each index is processed by at most one vacuum process.  Therefore parallel  
vacuum can be used when the table has at least two indexes.  
  
The parallel degree is either specified by the user or determined based on  
the number of indexes that the table has, and further limited by  
max_parallel_maintenance_workers.  The index can participate in parallel  
vacuum iff it's size is greater than min_parallel_index_scan_size.  
  
Author: Masahiko Sawada and Amit Kapila  
Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra,  
Mahendra Singh and Sergei Kornilov  
Tested-by: Mahendra Singh and Prabhat Sahu  
Discussion:  
https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com  
https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com  

commit   : 44f1fc8df5dadbc5e80661660903aab4076d868f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 19:15:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 19:15:15 -0500    

ecpg_build_params() would crash on a null pointer dereference if  
realloc() failed, due to updating the persistent "stmt" struct  
too aggressively.  (Even without the crash, this would've leaked  
the old storage that we were trying to realloc.)  
  
Per Coverity.  This seems to have been broken in commit 0cc050794,  
so back-patch into v12.  

commit   : 9c679a08f0cdedcf7f084daea3cba6ae9c3cbced    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 16:04:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 16:04:36 -0500    

Ensure that ClassifyUtilityCommandAsReadOnly() has defined behavior  
even if TransactionStmt.kind has a value that's not one of the  
declared values for its enum.  
  
Suppress warnings from compilers that don't know that elog(ERROR)  
doesn't return, in ClassifyUtilityCommandAsReadOnly() and  
jsonb_set_lax().  
  
Per Coverity and buildfarm.  

commit   : 7aaefadaac6452b2e813fae4ea531cb12d022531    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 19 Jan 2020 13:54:58 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 19 Jan 2020 13:54:58 +0200    

This data was only in separate files because it was the most convenient  
way to handle it with a shell script. Now that we use a general-purpose  
programming language, it's easy to assemble the data into the same format  
as the rest of the catalogs and output it into postgres.bki. This allows  
removal of some special-purpose code from initdb.c.  
  
Discussion: https://www.postgresql.org/message-id/CACPNZCtVFtjHre6hg9dput0qRPp39pzuyA2A6BT8wdgrRy%2BQdA%40mail.gmail.com  
Author: John Naylor  

commit   : e0ed6817c0ee218a3681920807404603e042ff04    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 19 Jan 2020 18:55:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 19 Jan 2020 18:55:51 +0900    

Clarify the description related to the use of characters which can be  
encoded, and add an example.  
  
Author: Jobin Augustine  
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Heikki Linnakangas,  
Michael Paquier, Alex Shulgin  
Discussion: https://postgr.es/m/CANaTPsrYgSgE2fuj3=4x=Jmx1c+NgkEDzftNknZbrMuqL+aBhQ@mail.gmail.com  

commit   : 34a0a81bfb388504deaa51b16a8bb531b827e519    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jan 2020 17:51:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jan 2020 17:51:03 -0500    

Rather than intermixing the discussion of text-string and binary-string  
functions, make a clean break, moving all discussion of binary-string  
operations into section 9.5.  This involves some duplication of  
function descriptions between 9.4 and 9.5, but it seems cleaner on the  
whole since the individual descriptions are clearer (and on the other  
side of the coin, it gets rid of some duplicated descriptions, too).  
  
Move the convert*/encode/decode functions to a separate table, because  
they don't quite seem to fit under the heading of "binary string  
functions".  
  
Also provide full documentation of the textual formats supported by  
encode() and decode() (which was the original goal of this patch  
series, many moons ago).  
  
Also move the table of built-in encoding conversions out of section 9.4,  
where it no longer had any relevance whatsoever, and put it into section  
23.3 about character sets.  I chose to put both that and table 23.2  
(multibyte-translation-table) into a new <sect2> so as not to break up  
the flow of discussion in 23.3.3.  
  
Also do a bunch of minor copy-editing on the function descriptions  
in 9.4 and 9.5.  
  
Karl Pinc, reviewed by Fabien Coelho, further hacking by me  
  
Discussion: https://postgr.es/m/20190304163347.7bca4897@slate.meme.com  

commit   : 41aadeeb124ee5f8e7d154a16a74d53286882b74    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jan 2020 12:32:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jan 2020 12:32:43 +0900    

Mixing incorrect bounds set in the SSL context leads to confusing error  
messages generated by OpenSSL which are hard to act on.  New checks are  
added within the GUC machinery to improve the user experience as they  
apply to any SSL implementation, not only OpenSSL, and doing the checks  
beforehand avoids the creation of a SSL during a reload (or startup)  
which we know will never be used anyway.  
  
Backpatch down to 12, as those parameters have been introduced by  
e73e67c.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200114035420.GE1515@paquier.xyz  
Backpatch-through: 12  

commit   : 4b754d6c16e16cc1a1adf12ab0f48603069a0efd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 18 Jan 2020 01:11:39 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 18 Jan 2020 01:11:39 +0300    

The strategy of GIN index scan is driven by opclass-specific extract_query  
method.  This method that needed search mode is GIN_SEARCH_MODE_ALL.  This  
mode means that matching tuple may contain none of extracted entries.  Simple  
example is '!term' tsquery, which doesn't need any term to exist in matching  
tsvector.  
  
In order to handle such scan key GIN calculates virtual entry, which contains  
all TIDs of all entries of attribute.  In fact this is full scan of index  
attribute.  And typically this is very slow, but allows to handle some queries  
correctly in GIN.  However, current algorithm calculate such virtual entry for  
each GIN_SEARCH_MODE_ALL scan key even if they are multiple for the same  
attribute.  This is clearly not optimal.  
  
This commit improves the situation by introduction of "exclude only" scan keys.  
Such scan keys are not capable to return set of matching TIDs.  Instead, they  
are capable only to filter TIDs produced by normal scan keys.  Therefore,  
each attribute should contain at least one normal scan key, while rest of them  
may be "exclude only" if search mode is GIN_SEARCH_MODE_ALL.  
  
The same optimization might be applied to the whole scan, not per-attribute.  
But that leads to NULL values elimination problem.  There is trade-off between  
multiple possible ways to do this.  We probably want to do this later using  
some cost-based decision algorithm.  
  
Discussion: https://postgr.es/m/CAOBaU_YGP5-BEt5Cc0%3DzMve92vocPzD%2BXiZgiZs1kjY0cj%3DXBg%40mail.gmail.com  
Author: Nikita Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud  
Reviewed-by: Julien Rouhaud, Tomas Vondra, Tom Lane  

commit   : 41c6f9db25b5e3a8bb8afbb7d6715cff541fd41e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jan 2020 16:17:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jan 2020 16:17:17 -0500    

Commit 9b63c13f0 turns out to have been fundamentally misguided:  
the parent node's subPlan list is by no means the only way in which  
a child SubPlan node can be hooked into the outer execution state.  
As shown in bug #16213 from Matt Jibson, we can also get short-lived  
tuple table slots added to the outer es_tupleTable list.  At this point  
I have little faith that there aren't other possible connections as  
well; the long time it took to notice this problem shows that this  
isn't a heavily-exercised situation.  
  
Therefore, revert that fix, returning to the coding that passed a  
NULL parent plan pointer down to the transiently-built subexpressions.  
That gives us a pretty good guarantee that they won't hook into the  
outer executor state in any way.  But then we need some other solution  
to make SubPlans work.  Adopt the solution speculated about in the  
previous commit's log message: do expression initialization at plan  
startup for just those VALUES rows containing SubPlans, abandoning the  
goal of reclaiming memory intra-query for those rows.  In practice it  
seems unlikely that queries containing a vast number of VALUES rows  
would be using SubPlans in them, so this should not give up much.  
  
(BTW, this test case also refutes my claim in connection with the prior  
commit that the issue only arises with use of LATERAL.  That was just  
wrong: some variants of SubLink always produce SubPlans.)  
  
As with previous patch, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16213-871ac3bc208ecf23@postgresql.org  

commit   : 15cac3a523cc06dba1331635f3f67445fa202a44    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jan 2020 18:00:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jan 2020 18:00:39 -0300    

... specifically, set it incrementally as each individual change is  
spilled down to disk.  This way, it is set correctly when the  
transaction disappears without trace, ie. without leaving an XACT_ABORT  
wal record.  (This happens when the server crashes midway through a  
transaction.)  
  
Failing to have final_lsn prevents ReorderBufferRestoreCleanup() from  
working, since it needs the final_lsn in order to know the endpoint of  
its iteration through spilled files.  
  
Commit df9f682c7bf8 already tried to fix the problem, but it didn't set  
the final_lsn in all cases.  Revert that, since it's no longer needed.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Dilip Kumar  
Discussion: https://postgr.es/m/CALDaNm2CLk+K9JDwjYST0sPbGg5AQdvhUt0jbKyX_HdAE0jk3A@mail.gmail.com  

commit   : 543852fd8bf0adc56192aeb25ff83f1a12c30368    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:28 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:28 +0100    

The bitmap used by SlabCheck to cross-check free chunks in a block used  
to be allocated for each SlabCheck call, and was never freed. The memory  
leak could be fixed by simply adding a pfree call, but it's actually a  
bad idea to do any allocations in SlabCheck at all as it assumes the  
state of the memory management as a whole is sane.  
  
So instead we allocate the bitmap as part of SlabContext, which means  
we don't need to do any allocations in SlabCheck and the bitmap goes  
away together with the SlabContext.  
  
Backpatch to 10, where the Slab context was introduced.  
  
Author: Tomas Vondra  
Reported-by: Andres Freund  
Reviewed-by: Tom Lane  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20200116044119.g45f7pmgz4jmodxj%40alap3.anarazel.de  

commit   : 4b0e0f67f2f16c077b4e5c8a3d70c6af4355db09    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 16:24:13 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 16:24:13 +1030    

commit   : a83586b5543b948f9e621462537a7303b113c482    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 11:41:35 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 11:41:35 +1030    

jsonb_set_lax() is the same as jsonb_set, except that it takes and extra  
argument that specifies what to do if the value argument is NULL. The  
default is 'use_json_null'. Other possibilities are 'raise_exception',  
'return_target' and 'delete_key', all these behaviours having been  
suggested as reasonable by various users.  
  
Discussion: https://postgr.es/m/375873e2-c957-3a8d-64f9-26c43c2b16e7@2ndQuadrant.com  
  
Reviewed by: Pavel Stehule  

commit   : f7cd5896a69621818189fbdd209fb2e1fc008102    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2020 10:06:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2020 10:06:17 +0900    

Two routines have been added in OpenSSL 1.1.0 to set the protocol bounds  
allowed within a given SSL context:  
- SSL_CTX_set_min_proto_version  
- SSL_CTX_set_max_proto_version  
  
As Postgres supports OpenSSL down to 1.0.1 (as of HEAD), equivalent  
replacements exist in the tree, which are only available for the  
backend.  A follow-up patch is planned to add control of the SSL  
protocol bounds for libpq, so move those routines to src/common/ so as  
libpq can use them.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se  

commit   : 5afaa2e42655811461044c4216e2f821cadc766d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 18:08:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 18:08:21 -0500    

Move all the backend-only code that'd crept into wchar.c and encnames.c  
into mbutils.c.  
  
To remove the last few #ifdef dependencies from wchar.c and encnames.c,  
also make the following changes:  
  
* Adjust get_encoding_name_for_icu to return NULL, not throw an error,  
for unsupported encodings.  Its sole caller can perfectly well throw an  
error instead.  (While at it, I also made this function and its sibling  
is_encoding_supported_by_icu proof against out-of-range encoding IDs.)  
  
* Remove the overlength-name error condition from pg_char_to_encoding.  
It's completely silly not to treat that just like any other  
the-name-is-not-in-the-table case.  
  
Also, get rid of pg_mic_mblen --- there's no obvious reason why  
conv.c shouldn't call pg_mule_mblen instead.  
  
Other than that, this is just code movement and comment-polishing with  
no functional changes.  Notably, I reordered declarations in pg_wchar.h  
to show which functions are frontend-accessible and which are not.  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : 3d4cb5d6c180e38ebf84f6403cfa18c09d0b738e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:58:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:58:24 -0500    

Bring these into common style (including having proper copyright  
notices) and adjust their self-declaration of where they live.  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : e6afa8918c461c1dd80c5063a950518fa4e950cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:56:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:56:32 -0500    

Formerly, various frontend directories symlinked these two sources  
and then built them locally.  That's an ancient, ugly hack, and  
we now have a much better way: put them into libpgcommon.  
So do that.  (The immediate motivation for this is the prospect  
of having to introduce still more symlinking if we don't.)  
  
This commit moves these two files absolutely verbatim, for ease of  
reviewing the git history.  There's some follow-on work to be done  
that will modify them a bit.  
  
Robert Haas, Tom Lane  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : 2eb34ac369741c110b593e2dc2195c57d29ab8e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jan 2020 12:11:31 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jan 2020 12:11:31 -0500    

Previously, check_xact_readonly() was responsible for determining  
which types of queries could not be run in a read-only transaction,  
standard_ProcessUtility() was responsibility for prohibiting things  
which were allowed in read only transactions but not in recovery, and  
utility commands were basically prohibited in bulk in parallel mode by  
calls to CommandIsReadOnly() in functions.c and spi.c.  This situation  
was confusing and error-prone. Accordingly, move all the checks to a  
new function ClassifyUtilityCommandAsReadOnly(), which determines the  
degree to which a given statement is read only.  
  
In the old code, check_xact_readonly() inadvertently failed to handle  
several statement types that actually should have been prohibited,  
specifically T_CreatePolicyStmt, T_AlterPolicyStmt, T_CreateAmStmt,  
T_CreateStatsStmt, T_AlterStatsStmt, and T_AlterCollationStmt.  As a  
result, thes statements were erroneously allowed in read only  
transactions, parallel queries, and standby operation. Generally, they  
would fail anyway due to some lower-level error check, but we  
shouldn't rely on that.  In the new code structure, future omissions  
of this type should cause ClassifyUtilityCommandAsReadOnly() to  
complain about an unrecognized node type.  
  
As a fringe benefit, this means we can allow certain types of utility  
commands in parallel mode, where it's safe to do so. This allows  
ALTER SYSTEM, CALL, DO, CHECKPOINT, COPY FROM, EXPLAIN, and SHOW.  
It might be possible to allow additional commands with more work  
and thought.  
  
Along the way, document the thinking process behind the current set  
of checks, as per discussion especially with Peter Eisentraut. There  
is some interest in revising some of these rules, but that seems  
like a job for another patch.  
  
Patch by me, reviewed by Tom Lane, Stephen Frost, and Peter  
Eisentraut.  
  
Discussion: http://postgr.es/m/CA+TgmoZ_rLqJt5sYkvh+JpQnfX0Y+B2R+qfi820xNih6x-FQOQ@mail.gmail.com  

commit   : 0db7c67051806f28a9129d50695efc19372d3af2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 11:31:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 11:31:30 -0500    

Remove duplicated code (apparently introduced by commit c8ea87e4b).  
Also get rid of some PG_USED_FOR_ASSERTS_ONLY variables we don't  
really need to have.  
  
Li Japin, Tom Lane  
  
Discussion: https://postgr.es/m/PS1PR0601MB3770A5595B6E5E3FD6F35724B6360@PS1PR0601MB3770.apcprd06.prod.outlook.com  

commit   : 1281a5c907b41e992a66deb13c3aa61888a62268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jan 2020 18:49:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jan 2020 18:49:24 -0500    

We've had numerous bug reports about how (1) IF NOT EXISTS clauses in  
ALTER TABLE don't behave as-expected, and (2) combining certain actions  
into one ALTER TABLE doesn't work, though executing the same actions as  
separate statements does.  This patch cleans up all of the cases so far  
reported from the field, though there are still some oddities associated  
with identity columns.  
  
The core problem behind all of these bugs is that we do parse analysis  
of ALTER TABLE subcommands too soon, before starting execution of the  
statement.  The root of the bugs in group (1) is that parse analysis  
schedules derived commands (such as a CREATE SEQUENCE for a serial  
column) before it's known whether the IF NOT EXISTS clause should cause  
a subcommand to be skipped.  The root of the bugs in group (2) is that  
earlier subcommands may change the catalog state that later subcommands  
need to be parsed against.  
  
Hence, postpone parse analysis of ALTER TABLE's subcommands, and do  
that one subcommand at a time, during "phase 2" of ALTER TABLE which  
is the phase that does catalog rewrites.  Thus the catalog effects  
of earlier subcommands are already visible when we analyze later ones.  
(The sole exception is that we do parse analysis for ALTER COLUMN TYPE  
subcommands during phase 1, so that their USING expressions can be  
parsed against the table's original state, which is what we need.  
Arguably, these bugs stem from falsely concluding that because ALTER  
COLUMN TYPE must do early parse analysis, every other command subtype  
can too.)  
  
This means that ALTER TABLE itself must deal with execution of any  
non-ALTER-TABLE derived statements that are generated by parse analysis.  
Add a suitable entry point to utility.c to accept those recursive  
calls, and create a struct to pass through the information needed by  
the recursive call, rather than making the argument lists of  
AlterTable() and friends even longer.  
  
Getting this to work correctly required a little bit of fiddling  
with the subcommand pass structure, in particular breaking up  
AT_PASS_ADD_CONSTR into multiple passes.  But otherwise it's mostly  
a pretty straightforward application of the above ideas.  
  
Fixing the residual issues for identity columns requires refactoring of  
where the dependency link from an identity column to its sequence gets  
set up.  So that seems like suitable material for a separate patch,  
especially since this one is pretty big already.  
  
Discussion: https://postgr.es/m/10365.1558909428@sss.pgh.pa.us  

commit   : a166d408eb0b35023c169e765f4664c3b114b52e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jan 2020 11:02:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jan 2020 11:02:09 -0300    

This uses the progress reporting infrastructure added by c16dc1aca5e0,  
adding support for ANALYZE.  
  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>  
Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi,  
	Vignesh C, Amit Langote  

commit   : 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jan 2020 10:15:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jan 2020 10:15:06 +0100    

For historical reasons, libpq used a separate libpq.rc file for the  
Windows builds while all other components use a common file  
win32ver.rc.  With a bit of tweaking, the libpq build can also use the  
win32ver.rc file.  This removes a bit of duplicative code.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/ad505e61-a923-e114-9f38-9867d161073f@2ndquadrant.com  

commit   : ac5bdf62617507b1942f6124a2696c04a16fca04    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jan 2020 13:58:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jan 2020 13:58:33 +0900    

The logic introduced in this routine as of 246a6c8 would report an  
incorrect result when a session calls it to check if the temporary  
namespace owned by the session is in use or not.  It is possible to  
optimize more the routine in this case to avoid a PGPROC lookup, but  
let's keep the logic simple.  As this routine is used only by autovacuum  
for now, there were no live bugs, still let's be correct for any future  
code involving it.  
  
Author: Michael Paquier  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/20200113093703.GA41902@paquier.xyz  
Backpatch-through: 11  

commit   : 4d8a8d0c738410ec02aab46b1ebe1835365ad384    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jan 2020 07:24:14 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jan 2020 07:24:14 +0530    

Introduce new fields amusemaintenanceworkmem and amparallelvacuumoptions  
in IndexAmRoutine for parallel vacuum.  The amusemaintenanceworkmem tells  
whether a particular IndexAM uses maintenance_work_mem or not.  This will  
help in controlling the memory used by individual workers as otherwise,  
each worker can consume memory equal to maintenance_work_mem.  The  
amparallelvacuumoptions tell whether a particular IndexAM participates in  
a parallel vacuum and if so in which phase (bulkdelete, vacuumcleanup) of  
vacuum.  
  
Author: Masahiko Sawada and Amit Kapila  
Reviewed-by: Dilip Kumar, Amit Kapila, Tomas Vondra and Robert Haas  
Discussion:  
https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com  
https://postgr.es/m/CAA4eK1LmcD5aPogzwim5Nn58Ki+74a6Edghx4Wd8hAskvHaq5A@mail.gmail.com  

commit   : fe233366f2e3ca44609c805ce0604c1e2122c3f9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 23:59:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 23:59:18 +0100    

On 64-bit Windows, pid_t is long long int, so a %d format isn't  
enough.  

commit   : 0e936a2148472e6c364aee8c3e298dc16dc4240a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 13:13:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 13:13:04 -0500    

The new wording was determined to be more accurate.  Also, update  
release note links that reference these sections.  
  
Reported-by: rirans@comcast.net  
  
Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 344c26915136fa54c4a1bf54074ba15090b32721    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 11:28:07 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 11:28:07 -0500    

This reverts part of commit 7559d8ebfa.  The copyright script has  
already been updated to skip *.key files.  
  
Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20200102184059.GA25435@alvherre.pgsql  
  
Backpatch-through: master  

commit   : 7316f11be03863858fa7acb5eee97ec35c91fca4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 10:51:58 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 10:51:58 -0500    

Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20200102184059.GA25435@alvherre.pgsql  
  
Backpatch-through: master  

commit   : 329730827848f61eb8d353d5addcbd885fa823da    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:07:11 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:07:11 +0100    

If no permanent replication slot is configured using  
primary_slot_name, the walreceiver now creates and uses a temporary  
replication slot.  A new setting wal_receiver_create_temp_slot can be  
used to disable this behavior, for example, if the remote instance is  
out of replication slots.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com  

commit   : ee4ac46c8eb289bc200d0fd682e75d11b4c55b5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:05:25 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:05:25 +0100    

This will be used by a subsequent patch.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com  

commit   : f595117e24a79db6072979ab5a757431fd17232f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 13:09:31 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 13:09:31 +0100    

Add an ALTER TABLE subcommand for dropping the generated property from  
a column, per SQL standard.  
  
Reviewed-by: Sergei Kornilov <sk@zsrv.org>  
Discussion: https://www.postgresql.org/message-id/flat/2f7f1d9c-946e-0453-d841-4f38eb9d69b6%402ndquadrant.com  

commit   : d751ba523546df2b2709c1ffd4d12d6a25e25bf6    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 14 Jan 2020 09:52:21 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 14 Jan 2020 09:52:21 +0000    

A view with conditional INSTEAD rules and no unconditional INSTEAD  
rules or INSTEAD OF triggers is not auto-updatable. Previously we  
relied on a check in the executor to catch this, but that's  
problematic since the planner may fail to properly handle such a query  
and thus return a particularly unhelpful error to the user, before  
reaching the executor check.  
  
Instead, trap this in the rewriter and report the correct error there.  
Doing so also allows us to include more useful error detail than the  
executor check can provide. This doesn't change the existing behaviour  
of updatable views; it merely ensures that useful error messages are  
reported when a view isn't updatable.  
  
Per report from Pengzhou Tang, though not adopting that suggested fix.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAG4reAQn+4xB6xHJqWdtE0ve_WqJkdyCV4P=trYr4Kn8_3_PEA@mail.gmail.com  

commit   : ed7bb5c311ce059294807cf4abfa9406d95feec0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 11 Jan 2020 10:24:48 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 11 Jan 2020 10:24:48 +0530    

This test was trying to test the mechanism to release kernel FDs as needed  
to get us under the max_safe_fds limit in case of spill files.  To do that,  
it needs to set max_files_per_process to a very low value which doesn't  
even permit starting of the server in the case when there are a few already  
opened files.  This test also won't work on platforms where we use one FD  
per semaphore.  
  
Backpatch-through: 10, till where this test was added  
Discussion:  
https://postgr.es/m/CAA4eK1LHhERi06Q+MmP9qBXBBboi+7WV3910J0aUgz71LcnKAw@mail.gmail.com  
https://postgr.es/m/6485.1578583522@sss.pgh.pa.us  

commit   : 7f380c59f800f7e0fb49f45a6ff7787256851a59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2020 15:04:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2020 15:04:31 -0500    

Previously, the core scanner's yy_transition[] array had 37045 elements.  
Since that number is larger than INT16_MAX, Flex generated the array to  
contain 32-bit integers.  By reimplementing some of the bulkier scanner  
rules, this patch reduces the array to 20495 elements.  The much smaller  
total length, combined with the consequent use of 16-bit integers for  
the array elements reduces the binary size by over 200kB.  This was  
accomplished in two ways:  
  
1. Consolidate handling of quote continuations into a new start condition,  
rather than duplicating that logic for five different string types.  
  
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence  
as three separate tokens, rather than one.  The logic to de-escape  
Unicode strings is moved to the filter code in parser.c, which already  
had the ability to provide special processing for token sequences.  
While we could have implemented the conversion in the grammar, that  
approach was rejected for performance and maintainability reasons.  
  
Performance in microbenchmarks of raw parsing seems equal or slightly  
faster in most cases, and it's reasonable to expect that in real-world  
usage (with more competition for the CPU cache) there will be a larger  
win.  The exception is UESCAPE sequences; lexing those is about 10%  
slower, primarily because the scanner now has to be called three times  
rather than one.  This seems acceptable since that feature is very  
rarely used.  
  
The psql and epcg lexers are likewise modified, primarily because we  
want to keep them all in sync.  Since those lexers don't use the  
space-hogging -CF option, the space savings is much less, but it's  
still good for perhaps 10kB apiece.  
  
While at it, merge the ecpg lexer's handling of C-style comments used  
in SQL and in C.  Those have different rules regarding nested comments,  
but since we already have the ability to keep track of the previous  
start condition, we can use that to handle both cases within a single  
start condition.  This matches the core scanner more closely.  
  
John Naylor  
  
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com  

commit   : 259bbe177808986e5d226ea7ce5a1ebb74657791    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jan 2020 13:27:39 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jan 2020 13:27:39 +0100    

The use of pg_atoi() for parsing a string into an Oid fails for values  
larger than INT32_MAX, since OIDs are unsigned.  Instead, use  
atooid().  While this has less error checking, the contents of the  
data directory are expected to be trustworthy, so we don't need to go  
out of our way to do full error checking.  
  
Discussion: https://www.postgresql.org/message-id/flat/dea47fc8-6c89-a2b1-07e3-754ff1ab094b%402ndquadrant.com  

commit   : 23d0dfa8fa016f7f8af25b1040d7a55ba77da6fc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 14:44:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 14:44:55 +0530    

Reported-by: Antonin Houska  
Author: Antonin Houska  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/2246.1578900133@antos  

commit   : 7689d907bbb177fa2a8f5aca3f968761dd16bf28    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jan 2020 17:57:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jan 2020 17:57:38 +0900    

Improvement per suggestion from Tom Lane.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/FED18699-4270-4778-8DA8-10F119A5ECF3@yesql.se  

commit   : cebf9d6e6ee13cbf9f1a91ec633cf96780ffc985    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jan 2020 18:08:09 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jan 2020 18:08:09 +1030    

Othrwise there is a security risk.  
  
Discussion: https://postgr.es/m/20200109103014.GA4192@msg.df7cb.de  

commit   : 4e514c6180fbf71cf7a0171867c828c63afd1c37    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 07:59:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 07:59:44 +0530    

Earlier, we use to postpone deleting empty pages till the second stage of  
vacuum to amortize the cost of scanning internal pages.  However, that can  
sometimes (say vacuum is canceled or errored between first and second  
stage) delay the pages to be recycled.  
  
Another thing is that to facilitate deleting empty pages in the second  
stage, we need to share the information about internal and empty pages  
between different stages of vacuum.  It will be quite tricky to share this  
information via DSM which is required for the upcoming parallel vacuum  
patch.  
  
Also, it will bring the logic to reclaim deleted pages closer to nbtree  
where we delete empty pages in each pass.  
  
Overall, the advantages of deleting empty pages in each pass outweigh the  
advantages of postponing the same.  
  
Author: Dilip Kumar, with changes by Amit Kapila  
Reviewed-by: Sawada Masahiko and Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1LGr+MN0xHZpJ2dfS8QNQ1a_aROKowZB+MPNep8FVtwAA@mail.gmail.com  

commit   : eae056c19ee8f5ebc45ac0fe13181f91c8791e00    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    

Until now we've only used a single multivariate MCV list per relation,  
covering the largest number of clauses. So for example given a query  
  
    SELECT * FROM t WHERE a = 1 AND b =1 AND c = 1 AND d = 1  
  
and extended statistics on (a,b) and (c,d), we'd only pick and use one  
of them. This commit improves this by repeatedly picking and applying  
the best statistics (matching the largest number of remaining clauses)  
until no additional statistics is applicable.  
  
This greedy algorithm is simple, but may not be optimal. A different  
choice of statistics may leave fewer clauses unestimated and/or give  
better estimates for some other reason.  
  
This can however happen only when there are overlapping statistics, and  
selecting one makes it impossible to use the other. E.g. with statistics  
on (a,b), (c,d), (b,c,d), we may pick either (a,b) and (c,d) or (b,c,d).  
But it's not clear which option is the best one.  
  
We however assume cases like this are rare, and the easiest solution is  
to define statistics covering the whole group of correlated columns. In  
the future we might support overlapping stats, using some of the clauses  
as conditions (in conditional probability sense).  
  
Author: Tomas Vondra  
Reviewed-by: Mark Dilger, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20191028152048.jc6pqv5hb7j77ocp@development  

commit   : aaa6761876ba5b06a5c3fa914b2951ace1e31dee    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    

When considering functional dependencies during selectivity estimation,  
it's not necessary to bother with selecting the best extended statistic  
object and then use just dependencies from it. We can simply consider  
all applicable functional dependencies at once.  
  
This means we need to deserialie all (applicable) dependencies before  
applying them to the clauses. This is a bit more expensive than picking  
the best statistics and deserializing dependencies for it. To minimize  
the additional cost, we ignore statistics that are not applicable.  
  
Author: Tomas Vondra  
Reviewed-by: Mark Dilger  
Discussion: https://postgr.es/m/20191028152048.jc6pqv5hb7j77ocp@development  

commit   : 652686a334b437f57f9bd0e3baa5dbd245a9e15d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jan 2020 14:36:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jan 2020 14:36:59 -0500    

When estimating the selectivity of "range_var <@ range_constant" or  
"range_var @> range_constant", if the upper (or respectively lower)  
bound of the range_constant was above the last bin of the range_var's  
histogram, the code would access uninitialized memory and potentially  
crash (though it seems the probability of a crash is quite low).  
Handle the endpoint cases explicitly to fix that.  
  
While at it, be more paranoid about the possibility of getting NaN  
or other silly results from the range type's subdiff function.  
And improve some comments.  
  
Ordinarily we'd probably add a regression test case demonstrating  
the bug in unpatched code.  But it's too hard to get it to crash  
reliably because of the uninitialized-memory dependence, so skip that.  
  
Per bug #16122 from Adam Scott.  It's been broken from the beginning,  
apparently, so backpatch to all supported branches.  
  
Diagnosis by Michael Paquier, patch by Andrey Borodin and Tom Lane.  
  
Discussion: https://postgr.es/m/16122-eb35bc248c806c15@postgresql.org  

commit   : 1088729e84cc382270c592ac8c57c323836f40ca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jan 2020 22:43:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jan 2020 22:43:45 +0900    

On the publisher, it was assumed that an INSERT change cannot happen for  
a relation with no replica identity.  However this is true only for a  
change that needs references to old rows, aka UPDATE or DELETE, so  
trying to use logical replication with a relation that has no replica  
identity led to an assertion failure in the publisher when issuing an  
INSERT.  This commit removes the incorrect assertion, and adds more  
regression tests to provide coverage for relations without replica  
identity.  
  
Reported-by: Neha Sharma  
Author: Dilip Kumar, Michael Paquier  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CANiYTQsL1Hb8_Km08qd32svrqNumXLJeoGo014O7VZymgOhZEA@mail.gmail.com  
Backpatch-through: 10  

commit   : 2c0cdc8183654c090c9a1e2f1b5e96ba4634e16a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2020 17:14:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2020 17:14:08 -0500    

Fix assorted bugs in handling of non-blocking I/O when using GSSAPI  
encryption.  The encryption layer could return the wrong status  
information to its caller, resulting in effectively dropping some data  
(or possibly in aborting a not-broken connection), or in a "livelock"  
situation where data remains to be sent but the upper layers think  
transmission is done and just go to sleep.  There were multiple small  
thinkos contributing to that, as well as one big one (failure to think  
through what to do when a send fails after having already transmitted  
data).  Note that these errors could cause failures whether the client  
application asked for non-blocking I/O or not, since both libpq and  
the backend always run things in non-block mode at this level.  
  
Also get rid of use of static variables for GSSAPI inside libpq;  
that's entirely not okay given that multiple connections could be  
open at once inside a single client process.  
  
Also adjust a bunch of random small discrepancies between the frontend  
and backend versions of the send/receive functions -- except for error  
handling, they should be identical, and now they are.  
  
Also extend the Kerberos TAP tests to exercise cases where nontrivial  
amounts of data need to be pushed through encryption.  Before, those  
tests didn't provide any useful coverage at all for the cases of  
interest here.  (They still might not, depending on timing, but at  
least there's a chance.)  
  
Per complaint from pmc@citylink and subsequent investigation.  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org  

commit   : c67a55da4ea0caa18547fd1533110e9126ba8d47    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jan 2020 09:00:19 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jan 2020 09:00:19 +0100    

Some callers are not using it, so it's wasteful to have to specify it.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA+fd4k4BcYrYucNfTnK-CQX3+jsG+PRPEhHAUSo-W4P0Lec57A@mail.gmail.com  

commit   : c096a804d9dcc46f1a8ebf2742696aca90b2dfcf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Dec 2019 09:09:20 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Dec 2019 09:09:20 +0100    

Replace the solitary use with a bool.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/a6f91ead-0ce4-2a34-062b-7ab9813ea308%402ndquadrant.com  

commit   : 38fc056074e034087af8a1589507631682a279d1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 10 Jan 2020 18:31:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 10 Jan 2020 18:31:22 -0800    

FileClose() failure ordinarily causes a PANIC.  Suppose the user  
disables that PANIC via data_sync_retry=on.  After mdclose() issued a  
FileClose() that failed, calls into md.c raised SIGSEGV.  This fix adds  
repalloc() calls during mdclose(); update a comment about ignoring  
repalloc() cost.  The rate of relation segment count change is a minor  
factor; more relevant to overall performance is the rate of mdclose()  
and subsequent re-opening of segments.  Back-patch to v10, where commit  
45e191e3aa62d47a8bc1a33f784286b2051f45cb introduced the bug.  
  
Reviewed by Kyotaro Horiguchi.  
  
Discussion: https://postgr.es/m/20191222091930.GA1280238@rfd.leadboat.com  

commit   : 1a4a0329650b0545a54afb3c317aa289fd817f8a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:15:28 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:15:28 -0800    

Author: Peter Geoghegan  
Reviewed-By: Heikki Linnakangas  

commit   : a0dc3c19ed1cffed6616f8b8b5f21ad7d6830045    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:12:50 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:12:50 -0800    

Author: Peter Geoghegan  
Reviewed-By: Heikki Linnakangas  

commit   : a7b6ab5db1d35438112f74f3531354ddd61970b5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2020 17:46:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2020 17:46:57 -0300    

This simplifies addition of further flags.  
  
Author: Nikhil Sontakke  
Discussion: https://postgr.es/m/CAMGcDxeViP+R-OL7QhzUV9eKCVjURobuY1Zijik4Ay_Ddwo4Cg@mail.gmail.com  

commit   : 00b047fa67e9f4428a682bd90d5e6b08d2f8a87b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:36:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:36:55 +0900    

Reported-by: Tham Nguyen  
Discussion: https://postgr.es/m/157851402876.29175.12977878383183540468@wrigleys.postgresql.org  
Backpatch-through: 9.4  

commit   : 39a5f2a94f8a3bcfdb3da7391427a63f8f88b210    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:02:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:02:25 +0900    

This is a follow-up of 30a3e772, making the output more consistent when  
using --debug for meta-command execution.  
  
Author: Michael Paquier  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1912241100390.3339@pseudo  

commit   : e7ee433137b6eb3678deeebc68be53d58aa1e5d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 16:46:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 16:46:05 -0500    

Experience so far suggests that getting these tests to pass on  
all libedit versions that are out there may be impossible, or  
require dumbing down the tests to the point of uselessness.  
So we need to provide a way to skip them when the user knows they'll  
fail.  An environment variable is probably the most convenient way  
to deal with this; it's easy for, e.g., a buildfarm animal's  
configuration to set up.  
  
Discussion: https://postgr.es/m/9594.1578586797@sss.pgh.pa.us  

commit   : 9ce77d75c5ab094637cc4a446296dc3be6e3c221    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 11:56:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 11:56:59 -0500    

The core idea of this patch is to make the parser generate join alias  
Vars (that is, ones with varno pointing to a JOIN RTE) only when the  
alias Var is actually different from any raw join input, that is a type  
coercion and/or COALESCE is necessary to generate the join output value.  
Otherwise just generate varno/varattno pointing to the relevant join  
input column.  
  
In effect, this means that the planner's flatten_join_alias_vars()  
transformation is already done in the parser, for all cases except  
(a) columns that are merged by JOIN USING and are transformed in the  
process, and (b) whole-row join Vars.  In principle that would allow  
us to skip doing flatten_join_alias_vars() in many more queries than  
we do now, but we don't have quite enough infrastructure to know that  
we can do so --- in particular there's no cheap way to know whether  
there are any whole-row join Vars.  I'm not sure if it's worth the  
trouble to add a Query-level flag for that, and in any case it seems  
like fit material for a separate patch.  But even without skipping the  
work entirely, this should make flatten_join_alias_vars() faster,  
particularly where there are nested joins that it previously had to  
flatten recursively.  
  
An essential part of this change is to replace Var nodes'  
varnoold/varoattno fields with varnosyn/varattnosyn, which have  
considerably more tightly-defined meanings than the old fields: when  
they differ from varno/varattno, they identify the Var's position in  
an aliased JOIN RTE, and the join alias is what ruleutils.c should  
print for the Var.  This is necessary because the varno change  
destroyed ruleutils.c's ability to find the JOIN RTE from the Var's  
varno.  
  
Another way in which this change broke ruleutils.c is that it's no  
longer feasible to determine, from a JOIN RTE's joinaliasvars list,  
which join columns correspond to which columns of the join's immediate  
input relations.  (If those are sub-joins, the joinaliasvars entries  
may point to columns of their base relations, not the sub-joins.)  
But that was a horrid mess requiring a lot of fragile assumptions  
already, so let's just bite the bullet and add some more JOIN RTE  
fields to make it more straightforward to figure that out.  I added  
two integer-List fields containing the relevant column numbers from  
the left and right input rels, plus a count of how many merged columns  
there are.  
  
This patch depends on the ParseNamespaceColumn infrastructure that  
I added in commit 5815696bc.  The biggest bit of code change is  
restructuring transformFromClauseItem's handling of JOINs so that  
the ParseNamespaceColumn data is propagated upward correctly.  
  
Other than that and the ruleutils fixes, everything pretty much  
just works, though some processing is now inessential.  I grabbed  
two pieces of low-hanging fruit in that line:  
  
1. In find_expr_references, we don't need to recurse into join alias  
Vars anymore.  There aren't any except for references to merged USING  
columns, which are more properly handled when we scan the join's RTE.  
This change actually fixes an edge-case issue: we will now record a  
dependency on any type-coercion function present in a USING column's  
joinaliasvar, even if that join column has no references in the query  
text.  The odds of the missing dependency causing a problem seem quite  
small: you'd have to posit somebody dropping an implicit cast between  
two data types, without removing the types themselves, and then having  
a stored rule containing a whole-row Var for a join whose USING merge  
depends on that cast.  So I don't feel a great need to change this in  
the back branches.  But in theory this way is more correct.  
  
2. markRTEForSelectPriv and markTargetListOrigin don't need to recurse  
into join alias Vars either, because the cases they care about don't  
apply to alias Vars for USING columns that are semantically distinct  
from the underlying columns.  This removes the only case in which  
markVarForSelectPriv could be called with NULL for the RTE, so adjust  
the comments to describe that hack as being strictly internal to  
markRTEForSelectPriv.  
  
catversion bump required due to changes in stored rules.  
  
Discussion: https://postgr.es/m/7115.1577986646@sss.pgh.pa.us  

commit   : ed10f32e37e9a16814c25e400d7826745ae3c797    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 10:59:07 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 10:59:07 -0500    

This tells you about allocations that have been made from the main  
shared memory segment. The original patch also tried to show information  
about dynamic shared memory allocation as well, but I decided to  
leave that problem for another time.  
  
Andres Freund and Robert Haas, reviewed by Michael Paquier, Marti  
Raudsepp, Tom Lane, Álvaro Herrera, and Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/20140504114417.GM12715@awork2.anarazel.de  

commit   : 5acf6d8bb4ec23349604c7c15111959e657ff294    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 09:01:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 09:01:37 -0500    

Per the buildfarm, via Michael Paquier.  
  
Discussion: http://postgr.es/m/20200108032648.GE3413@paquier.xyz  

commit   : e3019f631d1f2e21667ad05f903c52d904b9048c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jan 2020 10:48:22 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jan 2020 10:48:22 +0100    

Reported-by: Octopus ZHANG  
Author: Daniel Gustafsson  

commit   : f85a485f89e2eb38499558c7489f108994410952    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jan 2020 09:54:47 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jan 2020 09:54:47 +0100    

We currently have several sets of files generated from data provided  
by Unicode.  These all have ad hoc rules and instructions for updating  
when new Unicode versions appear, and it's not done consistently.  
  
This patch centralizes and automates the process and makes it part of  
the release checklist.  The Unicode and CLDR versions are specified in  
Makefile.global.in.  There is a new make target "update-unicode" that  
downloads all the relevant files and runs the generation script.  
  
There is also a new script for generating the table of combining  
characters for ucs_wcwidth().  That table is now in a separate include  
file rather than hardcoded into the middle of other code.  This is  
based on the script that was used for generating  
d8594d123c155aeecd47fc2450f62f5100b2fbf0, but the script itself wasn't  
committed at that time.  
  
Reviewed-by: John Naylor <john.naylor@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c8d05f42-443e-6c23-819b-05b31759a37c@2ndquadrant.com  

commit   : f5fd995a1a24e6571d26b1e29c4dc179112b1003    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Jan 2020 18:39:54 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Jan 2020 18:39:54 +1030    

This allows different users to authenticate with different certificates.  
  
Author: Craig Ringer  

commit   : 45223fd9cefe483daa4af7740f15c004486636eb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    

Change the exception syntax used in the tests to use the more current  
  
    except Exception as ex:  
  
rather than the old  
  
    except Exception, ex:  
  
Since support for Python <2.6 has been removed, all supported versions  
now support the new style, and we can save one step in the Python 3  
compatibility conversion.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com  

commit   : 37f21ed132d1c5aee88e81fee0a0b7e735673d35    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    

Supporting very old Python versions is a maintenance burden,  
especially with the several variant test files to maintain for Python  
<2.6.  
  
Since we have dropped support for older OpenSSL versions in  
7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, RHEL 5 is now effectively  
desupported, and that was also the only mainstream operating system  
still using Python versions before 2.6, so it's a good time to drop  
those as well.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com  

commit   : f5d28710c707ad602cd869602e092cc9d538cbb9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jan 2020 14:33:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jan 2020 14:33:49 -0300    

Make the value null only at pg_stat_activity-output time, as suggested  
by Tom Lane, instead of messing with the internal state.  This should  
appease buildfarm members with force_parallel_mode=regress, which are  
running parallel queries on logical replication walsenders.  
  
The fact that walsenders can run parallel queries should perhaps be  
studied more carefully, but for the moment let's get rid of the red  
blots in buildfarm.  
  
Backpatch to pg10, like the previous commit.  
  
Discussion: https://postgr.es/m/30804.1578438763@sss.pgh.pa.us  

commit   : 913bbd88dc6b859c70ebb48107b38d693c4c6673    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 11:07:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 11:07:53 -0500    

Use the parser's standard type coercion machinery to convert the  
output column(s) of a SQL function's final SELECT or RETURNING  
to the type(s) they should have according to the function's declared  
result type.  We'll allow any case where an assignment-level  
coercion is available.  Previously, we failed unless the required  
coercion was a binary-compatible one (and the documentation ignored  
this, falsely claiming that the types must match exactly).  
  
Notably, the coercion now accounts for typmods, so that cases where  
a SQL function is declared to return a composite type whose columns  
are typmod-constrained now behave as one would expect.  Arguably  
this aspect is a bug fix, but the overall behavioral change here  
seems too large to consider back-patching.  
  
A nice side-effect is that functions can now be inlined in a  
few cases where we previously failed to do so because of type  
mismatches.  
  
Discussion: https://postgr.es/m/18929.1574895430@sss.pgh.pa.us  

commit   : 8dd1511e39acd729020e151deb15a958300ebff5    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 8 Jan 2020 10:57:09 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 8 Jan 2020 10:57:09 -0500    

The original comment was a bit confusing, pointed out by Alvaro Herrera.  
  
Thread: https://postgr.es/m/20191224151520.GA16435%40alvherre.pgsql  

commit   : 4ac8aaa36fa24639989849c8109f8b52e9544fd1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 09:42:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 09:42:53 -0500    

ALTER TABLE failed if a column referenced in a GENERATED expression  
had been added or changed in type earlier in the ALTER command.  
That's because the GENERATED expression needs to be evaluated  
against the table's updated tuples, but it was being evaluated  
against the original tuples.  (Fortunately the executor has adequate  
cross-checks to notice the mismatch, so we just got an obscure error  
message and not anything more dangerous.)  
  
Per report from Andreas Joseph Krogh.  Back-patch to v12 where  
GENERATED was added.  
  
Discussion: https://postgr.es/m/VisenaEmail.200.231b0a41523275d0.16ea7f800c7@tc7-visena  

commit   : 30a3e772b4013d6593e4141cebd5ebfaff4d71a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 14:23:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 14:23:55 +0100    

Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1912241100390.3339@pseudo  

commit   : 65192e02441cedd106b6abebe0036fb8cc124fb3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:36:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:36:12 +0900    

This reverts commit a052f6c, following complains from Robert Haas and  
Tom Lane.  Backpatch down to 9.4, like the previous commit.  
  
Discussion: https://postgr.es/m/CA+TgmobL4npEX5=E5h=5Jm_9mZun3MT39Kq2suJFVeamc9skSQ@mail.gmail.com  
Backpatch-through: 9.4  

commit   : b0b6196386681383b8f0cb76df4fd35178a7371e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:02:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:02:55 +0900    

Failures in allocations could lead to crashes with NULL pointer  
dereferences .  Memory context TopMemoryContext is used instead to keep  
alive the plans allocated in the session.  A more specific context could  
be used here, but this is left for later.  
  
Reported-by: Jian Zhang  
Author: Michael Paquier  
Reviewed-by: Tom Lane, Andres Freund  
Discussion: https://postgr.es/m/16190-70181c803641c3dc@postgresql.org  

commit   : b175bd59fa54a90d21bc541f812643ac45281b98    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jan 2020 17:38:48 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jan 2020 17:38:48 -0300    

Returning a non-NULL time is pointless, sinc a walsender is not a  
process that would be running normal transactions anyway, but the code  
was unintentionally exposing the process start time intermittently,  
which was not only bogus but it also confused monitoring systems looking  
for idle transactions.  Fix by avoiding all updates in walsenders.  
  
Backpatch to 11, where walsenders started appearing in pg_stat_activity.  
  
Reported-by: Tomas Vondra  
Discussion: https://postgr.es/m/20191209234409.exe7osmyalwkt5j4@development  

commit   : ce242ae154dde3217971c6f262705d80999f4e00    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:35:48 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:35:48 -0500    

Instead of always calling heap_fetch_toast_slice during detoasting,  
invoke a table AM callback which, when the toast table is a heap  
table, will be heap_fetch_toast_slice.  
  
This makes it possible for a table AM other than heap to be used  
as a TOAST table. It also completes the series of commits intended  
to improve the interaction of tableam with TOAST that began with  
commit 8b94dab06617ef80a0901ab103ebd8754427ef5a; detoast.c is  
now, hopefully, fully AM-independent.  
  
Patch by me, reviewed by Andres Freund and Peter Eisentraut.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 83322e38da1aa054e1b144cb37e6074a86854199    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:23:25 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:23:25 -0500    

Previously, the toast table had to be implemented by the same AM that  
was used for the main table, which was bad, because the detoasting  
code won't work with anything but heap. This commit doesn't fix the  
latter problem, although there's another patch coming which does,  
but it does let you pick something that works (i.e. heap, right now).  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 814727858918154bdde9dbdfb99c544b52eb8818    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 12:14:19 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 12:14:19 -0500    

This one-line change provoked a lot of discussion, but ultimately  
the consensus seems to be that allowing a larger value might be  
useful to somebody, and probably won't hurt anyone who chooses  
not to take advantage of the higher maximum limit.  
  
Vyacheslav Makarov, reviewed by many people.  
  
Discussion: http://postgr.es/m/7b5ecc5a9991045e2f13c84e3047541d@postgrespro.ru  

commit   : 2bd0735b954b14dcfab85d57fc4a0c7f9826fbb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 20:56:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 20:56:32 -0500    

Instead of hard-wiring the netmask as /32, allow it to be specified  
where we specify the server address.  This will ease changing the  
test to use IPv6, when/if somebody wants to do that.  
  
Also remove the hard-wired pg_hba.conf entries for IPv6 (::1/128).  
These have never had any usefulness, because the client side  
of the tests has always explicitly connected to $SERVERHOSTADDR  
which has always been set to IPv4 (127.0.0.1).  All they accomplish  
is to break the test on non-IPv6-supporting hosts, and besides  
that they violate the express intent of the code to minimize the  
server's range of allowed connections.  
  
This could be back-patched, perhaps, but for now I don't see  
a need to.  
  
Discussion: https://postgr.es/m/1899.1578356089@sss.pgh.pa.us  

commit   : e369f3708636c66718796fc8269d253432410392    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 16:42:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 16:42:20 -0500    

Since the WAL flush position only moves forward, it's safe to cache  
its previous value within each walsender process, and update from  
shared memory only once we've caught up to the previously-seen value.  
When there are many active walsenders, this makes for a very significant  
reduction in the amount of contention on the XLogCtl->info_lck spinlock.  
  
This patch also adjusts the logic so that we update our idea of the  
flush position after processing a WAL record, rather than beforehand.  
This may cause us to realize we're not caught up when the preceding  
coding would've thought that we were, but that seems all to the good;  
it may avoid a useless sleep-and-wakeup cycle.  
  
Back-patch to v12.  The contention problem exists in prior branches,  
but it's much less severe (due to inefficiencies elsewhere) so there  
seems no need to take any risk of back-patching further.  
  
Pierre Ducroquet, reviewed by Julien Rouhaud  
  
Discussion: https://postgr.es/m/2931018.Vxl9zapr77@pierred-pdoc  

commit   : 20d6225d1656102534a73d9675bc531ff0e5203b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 12:13:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 12:13:53 -0500    

These allow better control of trailing zeroes in numeric values.  
  
Pavel Stehule, based on an old proposal of Marko Tiikkaja's;  
review by Karl Pinc  
  
Discussion: https://postgr.es/m/CAFj8pRDjs-navGASeF0Wk74N36YGFJ+v=Ok9_knRa7vDc-qugg@mail.gmail.com  

commit   : b9c130a1fdf16cd99afb390c186d19acaea7d132    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jan 2020 08:21:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jan 2020 08:21:14 +0100    

The logical replication apply worker did not fire per-column update  
triggers because the updatedCols bitmap in the RTE was not populated.  
This fixes that.  
  
Reviewed-by: Euler Taveira <euler@timbira.com.br>  
Discussion: https://www.postgresql.org/message-id/flat/21673e2d-597c-6afe-637e-e8b10425b240%402ndquadrant.com  

commit   : 7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jan 2020 12:51:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jan 2020 12:51:44 +0900    

Support is out of scope from all the major vendors for these versions  
(for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1),  
and it created some extra maintenance work.  Upstream has stopped  
support of 0.9.8 in December 2015 and of 1.0.0 in February 2016.  
  
Since b1abfec, note that the default SSL protocol version set with  
ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL  
1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1  
in the SSL tests.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz  

commit   : fc3100112395485f1c65848b273b3235de4aad07    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 5 Jan 2020 17:42:13 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 5 Jan 2020 17:42:13 -0800    

The fastpath insert optimization's incomplete split flag Assert() is  
redundant.  We'll reach the more general Assert() within  
_bt_findinsertloc() in all cases. (Besides, Assert()'ing that the  
rightmost page doesn't have the flag set never made much sense.)  

commit   : 8c081a2f4e8eec11747e709c1ea4c3485ef129dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jan 2020 11:35:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jan 2020 11:35:45 -0500    

Use qr// syntax for regex values.  
Include the regex that failed to match in diagnostic reports.  
  
Dagfinn Ilmari Mannsåker  
  
Discussion: https://postgr.es/m/87k16610xk.fsf@wibble.ilmari.org  

commit   : 955f1213012361e32d88976c3ce03ae62153c355    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 5 Jan 2020 19:45:37 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 5 Jan 2020 19:45:37 +0900    

Per suggestion from Tom Lane.  
Discussion: https://postgr.es/m/flat/20191230.093451.1762483750956466101.t-ishii%40sraoss.co.jp  

commit   : 48e03583cd373ce67827f4d8a99dcef8242364b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 21:33:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 21:33:34 -0500    

The true explanation for Peter Geoghegan's trouble report turns out  
to be that he has a ~/.inputrc that affects readline's behavior  
enough to break this test.  Prevent readline from reading that file.  
  
Also, the best way to prevent TERM from affecting the results seems  
to be to unset it altogether, not to set it to "xterm".  The latter  
choice licenses readline to emit xterm escape sequences, and there's  
a lot of variation in exactly what it will emit.  
  
Revert changes that attempted to account exactly for xterm escape  
sequences.  We shouldn't need that with TERM unset, and it was not  
looking like a maintainable solution anyway.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 7e42478186aa8b41a8706f3f53b44e25a427bde9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 16:40:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 16:40:56 -0500    

Right at the moment, this is making things worse not better in the  
buildfarm.  I'm not happy with anything about the current state,  
but let's at least try to have a green buildfarm report while further  
investigation continues.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 60ab7c80b4de2c3591e50dfb5ed0fd4002f0f2f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 15:05:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 15:05:24 -0500    

I'm curious to see what values are prevailing in the buildfarm.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 5b630501e9fa58c5069b36247d63fc460d912c7f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Jan 2020 11:31:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Jan 2020 11:31:42 -0800    

It has undefined behavior.  Follow the precedent of commit  
9a9473f3cce1a21c25d6cc7569710e832d2b180b.  No back-patch, since the  
master branch alone has this function.  
  
Discussion: https://postgr.es/m/20191229070221.GA13873@gust.leadboat.com  

commit   : fac1c04feca6d01f2d324088c5899485f55b6217    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 14:29:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 14:29:28 -0500    

Depending on as-yet-incompletely-explained factors, readline/libedit  
might choose to emit screen-control escape sequences as part of  
repainting the display.  I'd tried to make the test patterns avoid  
matching parts of the output that are likely to contain such, but  
it seems that there's really no way around matching them explicitly  
in some places, unless we want to just give up testing some behaviors  
such as display of alternatives.  
  
Per report from Peter Geoghegan.  
  
Discussion: https://postgr.es/m/CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com  

commit   : 3fd40b628c7db4c4bcf03b548f9a55f85e327e25    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Jan 2020 11:56:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Jan 2020 11:56:58 +0100    

Pass ParseState into the functions called from  
standard_ProcessUtility() instead passing the query string and query  
environment separately.  No functionality change, but it makes the  
notation consistent.  We had already started moving things into  
that direction piece by piece, and this completes it.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/6e7aa4a1-be6a-1a75-b1f9-83a678e5184a@2ndquadrant.com  

commit   : d2e5e20e57111cca9e14f6e5a99a186d4c66a5b7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Jan 2020 12:18:13 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Jan 2020 12:18:13 -0800    

Commit 558a9165e08 taught _bt_delitems_delete() to produce its own XID  
horizon on the primary.  Standbys no longer needed to generate their own  
latestRemovedXid, since they could just use the explicitly logged value  
from the primary instead.  The deleted offset numbers array from the  
xl_btree_delete WAL record was no longer used by the REDO routine for  
anything other than deleting the items.  
  
This enables a minor optimization:  We now treat the array as buffer  
state, not generic WAL data, following _bt_delitems_vacuum()'s example.  
This should be a minor win, since it allows us to avoid including the  
deleted items array in cases where XLogInsert() stores the whole buffer  
anyway.  The primary goal here is to make the code more maintainable,  
though.  Removing inessential differences between the two functions  
highlights the fundamental differences that remain.  
  
Also change xl_btree_delete to use uint32 for the size of the array of  
item offsets being deleted.  This brings xl_btree_delete closer to  
xl_btree_vacuum.  Furthermore, it seems like a good idea to use an  
explicit-width integer type (the field was previously an "int").  
  
Bump XLOG_PAGE_MAGIC because xl_btree_delete changed.  
  
Discussion: https://postgr.es/m/CAH2-Wzkz4TjmezzfAbaV1zYrh=fr0bCpzuJTvBe5iUQ3aUPsCQ@mail.gmail.com  

commit   : 56a3921a2f5102f804bd0ff741e144a0e6f1c0b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 12:54:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 12:54:13 -0500    

Escape non-printable characters in failure reports, by using Data::Dumper  
in Useqq mode.  Also, bump $Test::Builder::Level so the diagnostic  
references the calling line, and use diag() instad of note(),  
so it shows even in non-verbose mode (per request from Christoph Berg).  
  
Also, give up on trying to test for the specific way that readline  
chooses to overwrite existing text in the \DRD -> \drds test.  
There are too many variants, it seems, at least on the libedit  
side of things.  
  
Dagfinn Ilmari Mannsåker and Tom Lane  
  
Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de  

commit   : ddd87d564508bb1c80aac0a4439cfe74a3c203a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 11:15:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 11:15:26 -0500    

Debian unstable is shipping a broken version of libedit: it de-escapes  
words before passing them to the application's tab completion function,  
preventing us from recognizing backslash commands.  Fortunately,  
we have enough information available to dig the original text out of  
rl_line_buffer, so ignore the string argument and do that.  
  
I view this as a temporary workaround to get the affected buildfarm  
members back to green in the wake of 7c015045b.  I hope we can get  
rid of it once somebody fixes Debian's libedit; hence, no back-patch,  
at least for now.  
  
Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de  

commit   : 04334fde69132f335d9d70cfefe419bd1276b232    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Jan 2020 10:44:13 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Jan 2020 10:44:13 +0100    

Author: Fabien COELHO <coelho@cri.ensmp.fr>  

commit   : d5b6b6515b35b11c82ce620fa84c989f246068aa    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Jan 2020 10:52:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Jan 2020 10:52:46 +0530    

Reported-by: Jon Jensen  
Author: Jon Jensen  
Reviewed-by: Amit Kapila and Robert Haas  
Backpatch-through: 10  
Discussion: https://postgr.es/m/nycvar.YSQ.7.76.1912301807510.9899@ybpnyubfg  

commit   : 0c41c83d8ff44ed8f9753885e2c11b3277babcce    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 18:30:25 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 18:30:25 -0800    

Adjust a comment that describes how alignment of the new left page high  
key works in btree_xlog_split(), the nbtree page split REDO routine.  
The wording used before commit 2c03216d831 is much clearer, so go back  
to that.  

commit   : 90d7f6604b6ed2dcedee2884c3b01541600515cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 19:44:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 19:44:43 -0500    

Satisfy perlcritic, mostly.  Per buildfarm.  

commit   : 44e44bd258a71162444d41a1044c795f2c6dd3d1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 13:30:40 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 13:30:40 -0800    

The expectation within _bt_delitems_vacuum() is that caller has a  
super-exclusive/cleanup buffer lock (not just a pin and a write lock).  

commit   : 1fa846f1c9afe6bb185d4bb60bed8102a8eacb8f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2020 17:04:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2020 17:04:24 -0300    

When row triggers exist in partitioned partitions that are not either  
part of FKs or deferred unique constraints, they are not correctly  
cloned to their partitions.  That's because they are marked "internal",  
and those are purposefully skipped when doing the clone triggers dance.  
Fix by relaxing the condition on which internal triggers are skipped.  
  
Amit Langote initially diagnosed the problem and proposed a fix, but I  
used a different approach.  
  
Reported-by: Petr Fedorov  
Discussion: https://postgr.es/m/6b3f0646-ba8c-b3a9-c62d-1c6651a1920f@phystech.edu  

commit   : 7c015045b9141cc30272930ea88cfa5df47240b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 15:02:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 15:02:21 -0500    

Up to now, psql's tab-complete.c has had exactly no regression test  
coverage.  This patch is an experimental attempt to add some.  
  
This needs Perl's IO::Pty module, which isn't installed everywhere,  
so the test script just skips all tests if that's not present.  
There may be other portability gotchas too, so I await buildfarm  
results with interest.  
  
So far this just covers a few very basic keyword-completion and  
query-driven-completion scenarios, which should be enough to let us  
get a feel for whether this is practical at all from a portability  
standpoint.  If it is, there's lots more that can be done.  
  
Discussion: https://postgr.es/m/10967.1577562752@sss.pgh.pa.us  

commit   : 915c04f091f13dbbc0fde833e612dc90b70103ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 14:02:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 14:02:46 -0500    

On further reflection about commit 4d02eb017, it occurs to me that  
expandRTE() had better agree with what addRangeTableEntryForFunction()  
is doing.  So teach that about functions possibly having typmods, too.  

commit   : a412f469880ede9f52336a7b383905129c2b03a0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 10:57:15 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 10:57:15 -0800    

Make the function prototype order consistent with the definition order  
in nbtpage.c.  

commit   : 4d02eb017e3c1268762fd1a10ec3c569515c047d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 13:48:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 13:48:54 -0500    

One code path in addRangeTableEntryForFunction() neglected to assign  
a collation to the tupdesc entry it constructs (which is a bit odd  
considering the other path did do so).  This didn't matter before commit  
5815696bc, because nothing would look at the type data in this tupdesc;  
but now it does.  
  
While at it, make sure we assign the correct typmod as well.  Most  
function expressions don't have a determinate typmod, but some do.  
  
Per buildfarm, which showed failures in non-C collations, a case  
I'd not thought to test for this patch :-(  

commit   : 5815696bc66b3092f6361f53e0394909647042c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 11:29:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 11:29:01 -0500    

When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),  
it wasn't very tightly integrated into the parser's APIs.  In the wake of  
adding p_rtindex to that struct (commit b541e9acc), there is a good reason  
to make more use of it: by passing around ParseNamespaceItem pointers  
instead of bare RTE pointers, we can get rid of various messy methods for  
passing back or deducing the rangetable index of an RTE during parsing.  
Hence, refactor the addRangeTableEntryXXX functions to build and return  
a ParseNamespaceItem struct, not just the RTE proper; and replace  
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem  
rather than building one internally.  
  
Also, add per-column data (a ParseNamespaceColumn array) to each  
ParseNamespaceItem.  These arrays are built during addRangeTableEntryXXX,  
where we have column type data at hand so that it's nearly free to fill  
the data structure.  Later, when we need to build Vars referencing RTEs,  
we can use the ParseNamespaceColumn info to avoid the rather expensive  
operations done in get_rte_attribute_type() or expandRTE().  
get_rte_attribute_type() is indeed dead code now, so I've removed it.  
This makes for a useful improvement in parse analysis speed, around 20%  
in one moderately-complex test query.  
  
The ParseNamespaceColumn structs also include Var identity information  
(varno/varattno).  That info isn't actually being used in this patch,  
except that p_varno == 0 is a handy test for a dropped column.  
A follow-on patch will make more use of it.  
  
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us  

commit   : 198c7153dccb11950e3030dec564fdc6e59b4451    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Jan 2020 14:40:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Jan 2020 14:40:18 +0100    

The comment was apparently copy-and-pasted and did not reflect the  
actual test outcome.  

commit   : d207038053837ae9365df2776371632387f6f655    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 14 Dec 2019 11:41:37 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 14 Dec 2019 11:41:37 +0530    

Currently while decoding changes, if the number of changes exceeds a  
certain threshold, we spill those to disk.  And this happens for each  
(sub)transaction.  Now, while reading all these files, we don't close them  
until we read all the files.  While reading these files, if the number of  
such files exceeds the maximum number of file descriptors, the operation  
errors out.  
  
Use PathNameOpenFile interface to open these files as that internally has  
the mechanism to release kernel FDs as needed to get us under the  
max_safe_fds limit.  
  
Reported-by: Amit Khandekar  
Author: Amit Khandekar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CAJ3gD9c-sECEn79zXw4yBnBdOttacoE-6gAyP0oy60nfs_sabQ@mail.gmail.com  

commit   : 4b25f5d0ba0197af80e3af0de7441ca9c88c1e24    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 17:29:41 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 17:29:41 -0800    

_bt_delitems_vacuum() comments claimed that it isn't worth another scan  
of the page to avoid falsely unsetting the BTP_HAS_GARBAGE page flag  
hint (this happens to be the same wording that was removed from  
_bt_delitems_delete() by my recent commit fe97c61c).  The comments made  
little sense, though.  The issue can't have much to do with performing a  
second scan of the target leaf page, since an LP_DEAD test could easily  
be performed in the first scan of the page anyway (the scan that takes  
place in btvacuumpage() caller).  
  
Revise the explanation.  It makes much more sense to frame this as an  
issue about recovery conflicts.  _bt_delitems_vacuum() cannot easily  
generate an XID cutoff in the same way that _bt_delitems_delete() is  
designed to.  
  
Falsely unsetting the page flag is not ideal, and is likely to happen  
more often than was supposed by the original comments.  Explain why it  
usually isn't a problem in practice.  There may be an argument for  
_bt_delitems_vacuum() not clearing the BTP_HAS_GARBAGE bit, removing the  
question of it being falsely unset by VACUUM (there may even be an  
argument for not using a page level hint at all).  This can be revisited  
later.  

commit   : 823e739d4a7257cf0ca58fc6eff3c4cec308fccf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jan 2020 19:31:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jan 2020 19:31:41 -0500    

If we have, say, an int column that is left-joined to a bigint column  
with USING, the merged column is the int column promoted to bigint.  
GROUP BY's tests for whether grouping on the merged column allows a  
reference to the underlying column, or vice versa, should know about  
that relationship --- and they do.  But I nearly broke this case with  
an ill-advised optimization, so the lack of any test coverage for it  
seems like a bad idea.  

commit   : c5f3b53b0ef2e8ae78e7488148c12bfe5939ca17    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 11:32:07 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 11:32:07 -0800    

Commit fe97c61c updated LP_DEAD item deletion comments, but missed a  
minor discrepancy on the REDO side.  Fix it now.  
  
In passing, don't talk about the btree_xlog_vacuum() behavior within  
btree_xlog_delete().  The reliance on XLOG_HEAP2_CLEANUP_INFO records  
for recovery conflicts is already discussed within btvacuumpage() and  
mentioned again in passing above btree_xlog_vacuum(), which seems  
sufficient.  

commit   : 7559d8ebfa11d98728e816f6b655582ce41150f3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2020 12:21:45 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2020 12:21:45 -0500    

Backpatch-through: update all files in master, backpatch legal files through 9.4