Author: Gurjeet Singh
Discussion: https://postgr.es/m/CABwTF4U_5kEnH93PXZEuEsZHuoSSuBEOqC6pian8vDfLZSQJNA@mail.gmail.com

The old text still had an implicit reference to the virtual behavior,
which was not in the final patch.

Author: Tobias Bussmann <t.bussmann@gmx.net>

ecpg_build_params() failed to check for ecpg_alloc failure in one
newly-added code path, and leaked a temporary string in another path.
Errors in commit a1dc6ab4, spotted by Coverity.

ecpg_register_prepared_stmt() is pretty obviously checking the wrong
variable while trying to detect malloc failure.  Error in commit
a1dc6ab4, spotted by Coverity.

Reported-by: Alexander Lakhin
Author: Alexander Lakhin
Reviewed-by: Amit Kapila and Tom Lane
Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com

Change extension for Graphviz files from .dot to .gv.  The latter
appears to be the generally preferred one nowadays.

Discussion: https://www.postgresql.org/message-id/flat/71fe76d2-c7d7-2acc-6762-bbf9e61c566e%402ndquadrant.com

Reported-by: Euler Taveira
Author: Euler Taveira
Discussion: https://postgr.es/m/CAHE3wgjiA8DdnUzH9WqBLxdrUVvjDkKNdHx-MkEg9uV+HtpMfg@mail.gmail.com

Per bug #15819 from Koizumi Satoru.

Discussion: https://postgr.es/m/15819-e6191bef1f7334c0@postgresql.org

Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com

Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com

Some of the wrapper functions didn't match the callback names. Many of
them due to staying "consistent" with historic naming of the wrapped
functionality. We decided that for most cases it's more important to
be for tableam to be consistent going forward, than with the past.

The one exception is beginscan/endscan/...  because it'd have looked
odd to have systable_beginscan/endscan/... with a different naming
scheme, and changing the systable_* APIs would have caused way too
much churn (including breaking a lot of external users).

Author: Ashwin Agrawal, with some small additions by Andres Freund
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com

The access method name "amname" can be dumped as of 3b925e90, but
queries for backends older than 9.5 forgot to map it to a dummy NULL
value, causing the column to not be mapped to a number.  As a result,
pg_dump was throwing some spurious errors in its stderr output coming
from libpq:
pg_dump: column number -1 is out of range 0..36

Fix this issue by adding a mapping of "amname" to NULL to all the older
queries.

Discussion: https://postgr.es/m/20190522083038.GA16837@paquier.xyz
Author: Michael Paquier
Reviewed-by: Dmitry Dolgov, Andres Freund, Tom Lane

On master (after 700538) the old version's installed psql was used -
even when the old version might not actually be installed / might be
installed into a temporary directory. As commonly the case when just
executing make check for pg_upgrade, as $oldbindir is just the current
version's $bindir.

In the back branches, with --install specified, psql from the new
version's temporary installation was used, without --install (e.g for
NO_TEMP_INSTALL, cf 47b3c266), the new version's installed psql was
used (which might or might not exist).

Author: Andres Freund
Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de

When there were duplicate columns in the hash key list, the array
sizes could be miscomputed, resulting in access off the end of the
array. Adjust the computation to ensure the array is always large
enough.

(I considered whether the duplicates could be removed in planning, but
I can't rule out the possibility that duplicate columns might have
different hash functions assigned. Simpler to just make sure it works
at execution time regardless.)

Bug apparently introduced in fc4b3dea as part of narrowing down the
tuples stored in the hashtable. Reported by Colm McHugh of Salesforce,
though I didn't use their patch. Backpatch back to version 10 where
the bug was introduced.

Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com

This uses a method similar to 68a7c24f and now b8c6014a (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected.  Note that tablespaces do not have support for initial
privileges via pg_init_privs, so the same method needs to be applied
again.  It would be nice to merge all the logic generating ACL queries
in dumps under the same banner, but this requires extending the support
of pg_init_privs to objects that cannot use it yet, so this is left as
future work.

Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz
Author: Michael Paquier
Reviewed-by: Nathan Bossart
Backpatch-through: 9.6

This has been forgotten in 578b2297, which has removed support for WITH
OIDS.

Discussion: https://postgr.es/m/CALAY4q99FcFCoG6ddke0V-AksGe82L_+bhDWgEfgZBakB840zA@mail.gmail.com
Author: Surafel Temesgen

Make all the perl code look nice, too (for some value of "nice").

Switch to 2.1 version of pg_bsd_indent.  This formats
multiline function declarations "correctly", that is with
additional lines of parameter declarations indented to match
where the first line's left parenthesis is.

Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com

This is still using the 2.0 version of pg_bsd_indent.
I thought it would be good to commit this separately,
so as to document the differences between 2.0 and 2.1 behavior.

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

This code was still using the old style of forming a heap tuple rather
than using tuple slots.  This would be less efficient if a non-heap
access method was used.  And using tuple slots is actually quite a bit
faster when using heap as well.

Also add some test cases for generated columns with null values and
with varlena values.  This lack of coverage was discovered while
working on this patch.

Discussion: https://www.postgresql.org/message-id/flat/20190331025744.ugbsyks7czfcoksd%40alap3.anarazel.de

Commit 41b54ba7 allowed not only VACUUM but also ANALYZE options
to take a boolean argument. But it forgot to update the documentation
for ANALYZE. This commit adds the descriptions about those ANALYZE
boolean options into the documentation.

This patch also updates tab-completion for ANALYZE boolean options.

Reported-by: Kyotaro Horiguchi
Author: Fujii Masao
Reviewed-by: Masahiko Sawada, Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwHTUt-kuwgiwe8f0AvTnB+ySqJWh95jvmh-qcoKW9YA9g@mail.gmail.com

The original coding of this view relied on a correlated IN sub-query.
Our planner is not very bright about correlated sub-queries, and even
if it were, there's no way for it to know that the output of
pg_get_publication_tables() is duplicate-free, making the de-duplicating
semantics of IN unnecessary.  Hence, rewrite as a LATERAL sub-query.
This provides circa 100X speedup for me with a few hundred published
tables (the whole regression database), and things would degrade as
roughly O(published_relations * all_relations) beyond that.

Because the rules.out expected output changes, force a catversion bump.
Ordinarily we might not want to do that post-beta1; but we already know
we'll be doing a catversion bump before beta2 to fix pg_statistic_ext
issues, so it's pretty much free to fix it now instead of waiting for v13.

Per report and fix suggestion from PegoraroF10.

Discussion: https://postgr.es/m/1551385426763-0.post@n3.nabble.com

Move support function mention to the proper section, and reword.

Reported-by: Tom Lane

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

Clarify new restriction on recovery_target* variables.

Reported-by: Gaby Schilders

Discussion: reported via chat

Oversight in commit a1dc6ab4.

That leads to unsatisfied external references if the C compiler fails
to elide unused static functions.  Apparently, we have no buildfarm
members building HEAD that have that issue ... but such compilers still
exist in the wild.  Need to do something about that.

In passing, fix Berkeley-era typo in comment.

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

This uses a method similar to 68a7c24f, which guarantees that GRANT
commands using the WITH GRANT OPTION are dumped in a way so as cascading
dependencies are respected.  As databases do not have support for
initial privileges via pg_init_privs, we need to repeat again the same
ACL reordering method.

ACL for databases have been moved from pg_dumpall to pg_dump in v11, so
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and
v10.

Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org
Author: Nathan Bossart
Reviewed-by: Haribabu Kommi
Backpatch-through: 9.6

Commit 5af2e976 removed a bit too much from the test.sh invocation.
Per buildfarm.

Besides implementing the new statement this change fix some issues with the
parsing of PREPARE and EXECUTE statements. The different forms of these
statements are now all handled in a ujnified way.

Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com>

When $(MAKE) is present in a rule, make assumes that target is a
submake, and it doesn't need to buffer its output. But in this case
it's a shell script that needs buffered output. Avoid that heuristic,
by referring to $(MAKE) via an indirection.

Discussion: https://postgr.es/m/20190521004717.qsktdsugj3shagco@alap3.anarazel.de

For pg_upgrade's test we (unless prevented by the caller via via
NO_TEMP_INSTALL) built a separate installation. That causes an
unnecessary slowdown after the infrastructure introduced by
dcae5fac (and unnecessarily duplicates code).

Author: Andres Freund
Reviewed-By: Tom Lane
Discussion:
    https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67@alap3.anarazel.de
    https://postgr.es/m/20190521195209.qfzwfxvymguuwlu5@alap3.anarazel.de

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

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

Discussion: https://postgr.es/m/87y330d8ty.fsf@news-spur.riddles.org.uk

Mostly commit messages, attribution, and text, all suggested by Andres
Freund.

Discussion: https://postgr.es/m/20190520221719.pqgld3krjc2docr5@alap3.anarazel.de

The use of "set -x" to echo a subset of the test's commands might've
been a good idea during development of this test, but it's been stable
for long enough now that the extra output isn't very useful.  Also
our project expectations have been trending towards less output in
non-error cases; the fact that "set -x" produces output on stderr
is particularly annoying from that standpoint.  So get rid of it.

Also, pass "-A trust" to initdb explicitly so that it won't issue
a warning about "trust" being an insecure default.  This matches
what the TAP tests have done for a long time, and again gets rid
of some noise on stderr.

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

We're seeing occasional instability in the plans generated for
parallel queries on the "a_star" table hierarchy.  This suggests
that something is changing the planner's stats for those tables,
but that should not be happening within a regression test run.
To try to gather some information about what's happening, insert
additional queries to check the basic page/tuple counts for these
tables, as well as whether any vacuums or analyzes have happened
on them.  (We expect that only the database-wide VACUUM in
sanity_check.sql will have touched them.)

I added the probes not only in select_parallel.sql itself, but
also in stats.sql, bearing in mind that the stats collector's
lag may prevent the initial query from reporting current truth.
If any extra vacuum/analyze has happened, the recheck in stats.sql
definitely ought to see it.

This commit can be reverted once we figure out what's going on.

Per suggestion from David Rowley, though I changed the queries around.

Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com

This allows table AMs to completely suppress TOAST table creation, or
to modify the conditions under which they are created.

Patch by me.  Reviewed by Andres Freund.

Discussion: http://postgr.es/m/CA+Tgmoa4O2n=yphqD2pERUnYmUO84bH1SqMsA-nSxBGsZ7gWfA@mail.gmail.com

Define the meanings of the POSIX-spec character classes in line,
rather than referring to the ctype(3) man page.  That man page
doesn't even exist on many modern systems, and if it does exist
it probably says the wrong things about non-ASCII characters.
Also document our non-POSIX-spec "ascii" character class.

Also, point out here that this behavior is controlled by collation or
LC_CTYPE, since the existing text explaining that is pretty far away.

Per gripe from Geert Lobbestael.  Given the lack of prior complaints,
I'm not excited about back-patching this.

Discussion: https://postgr.es/m/155837022049.1359.2948065118562813468@wrigleys.postgresql.org