Handle various problems with sequence handling.

PG 10 changed the way sequences are stored in the catalogs. The merge broke
some of those things and this commit attempts to fix most of them. We still see
some sequence related failures in the regression tests, but some of the most
obvious failures are now fixed.

Fix leaking of small spilled subtransactions during logical decoding.

When, during logical decoding, a transaction gets too big, it's
contents get spilled to disk. Not just the top-transaction gets
spilled, but *also* all of its subtransactions, even if they're not
that large themselves.  Unfortunately we didn't clean up
such small spilled subtransactions from disk.

Fix that, by keeping better track of whether a transaction has been
spilled to disk.

Author: Andres Freund
Reported-By: Dmitriy Sarafannikov, Fabrízio de Royes Mello
Discussion:
    https://postgr.es/m/1457621358.355011041@f382.i.mail.ru
    https://postgr.es/m/CAFcNs+qNMhNYii4nxpO6gqsndiyxNDYV0S=JNq0v_sEE+9PHXg@mail.gmail.com
Backpatch: 9.4-, where logical decoding was introduced

Improve PostgreSQL 10.0 release note regarding pg_current_logfile().

Author: Yugo Nagata

Documentation spell checking and markup improvements

Fix copy/paste error in docs

Author: Julien Rouhaud <[email protected]>

doc: Fix typo

Author: Julien Rouhaud <[email protected]>

Randomize the choice of the initial ROUNDROBIN node

With roundrobin node, the initial node was always set to the first node
in the list. That works fine when inserting many rows at once (e.g. with
INSERT SELECT), but with single-row inserts this puts all data on the
first node, resulting in unbalanced distribution.

This randomizes the choice of the initial node, so that with single-row
inserts the ROUNDROBIN behaves a bit like RANDOM distribution.

This also removes unnecessary srand() call from RelationBuildLocator(),
located after a call to rand().

Prevent dropping distribution keys for MODULO

Due to a coding issue in IsDistColumnForRelId() it was possible to drop
columns that were used as modulo distribution keys. A simple example
demonstrates the behavior:

    CREATE TABLE t (a INT, b INT, c INT) DISTRIBUTE BY MODULO (a);
    ALTER TABLE t DROP COLUMN a;

    test=# \d+ t
                              Table "public.t"
     Column |  Type   | Modifiers | Storage | Stats target | Description
    --------+---------+-----------+---------+--------------+-------------
     b      | integer |           | plain   |              |
     c      | integer |           | plain   |              |
    Distribute By: MODULO(........pg.dropped.1........)
    Location Nodes: ALL DATANODES

With this commit, the ALTER TABLE command fails as expected:

    ERROR:  Distribution column cannot be dropped

The commit simplifies the coding a bit, and removes several functions
that were not needed anymore (and unused outside locator.c).

Add support for MODULO distribution on BIGINT

Until now BIGINT data type was not supported by MODULO distribution and
attempts to create such tables failed. This patch removes the limitation.

The compute_modulo() function originally used an optimized algorithm
from http://www.graphics.stanford.edu/~seander/bithacks.html (namely the
one described in section "Compute modulus division by (1 << s) - 1 in
parallel without a division operator") to compute the modulo. But that
algorithm version only supported 32-bit values, and so would require
changes to support 64-bit values. Instead, I've decided to simply drop
that code and use simple % operator, which should translate to IDIV
instruction.

Judging by benchmarks (MODULO on INTEGER column), switching to plain
modulo (%) might result in about 1% slowdown, but it might easily be
just noise caused by different binary layout due to code changes. In
fact, the simplified algorithm is much less noisy in this respect.

Rename plpgsql_1.out to plpgsq.out to match upstream

There's no plpgsql_1.out at the upstream, only plpgsql.out. So make it
consistent, which means the file will also receive upstream changes.

Resolve most regression failures in plpgsql suite

The fixed differences had mostly trivial causes:

1) The expected output was missing for several tests, most likely due to
   initial resolution of a merge conflict (while it was not possible to
   run the tests, making verification impossible). This includes blocks
   labeled as

     - Test handling of expanded arrays
     - Test for proper handling of cast-expression caching

   and a few more smaller ones.

2) Change in spelling of messages, e.g. from

     CONTEXT:  PL/pgSQL function footest() line 5 at EXECUTE statement

   to

     CONTEXT:  PL/pgSQL function footest() line 5 at EXECUTE

3) Change in displaying context for notices, warnings and errors, which
   was reworked by 0426f349effb6bde2061f3398a71db7180c97dd9. Since that
   commit we only show the context for errors by default.

doc: Fix typo

Author: Julien Rouhaud <[email protected]>

Set statement timestamp in apply worker

This ensures that triggers can see an up-to-date timestamp.

Reported-by: Konstantin Evteev <[email protected]>

Remove incorrect comment

Author: Michael Paquier <[email protected]>

Fix typos in comments

Author: Daniel Gustafsson <[email protected]>

Define HAVE_UCOL_STRCOLLUTF8 on Windows

This should normally be determined by a configure check, but until
someone figures out how to do that on Windows, it's better that the code
uses the new function by default.

Teach pgindent to skip files generated by bison or flex automatically.

If a .c or .h file corresponds to a .y or .l file, skip indenting it.
There's no point in reindenting derived files, and these files tend to
confuse pgindent.  (Which probably indicates a bug in BSD indent, but
I can't get excited about trying to fix it.)

For the same reasons, add src/backend/utils/fmgrtab.c to the set of
files excluded by src/tools/pgindent/exclude_file_patterns.

The point of doing this is that it makes it safe to run pgindent over
the tree without doing "make maintainer-clean" first.  While these are
not the only derived .c/.h files in the tree, they are the only ones
pgindent fails on.  Removing that prerequisite step results in one less
way to mess up a pgindent run, and it's necessary if we ever hope to get
to the ease of running pgindent via "make indent".

doc: Add note that COPY commands are published as INSERTs

Use RangeVarGetRelidExtended() in AlterSequence()

This allows us to combine the opening and the ownership check.

Reported-by: Robert Haas <[email protected]>

Fix ICU collation use on Windows

Windows uses a separate code path for libc locales.  The code previously
ended up there also if an ICU collation should be used, leading to a
crash.

Reported-by: Ashutosh Sharma <[email protected]>

doc: Add section about logical replication restrictions

Fix dependency, when changing a function's argument/return type.

When a new base type is created using the old-style procedure of first
creating the input/output functions with "opaque" in place of the base
type, the "opaque" argument/return type is changed to the final base type,
on CREATE TYPE. However, we did not create a pg_depend record when doing
that, so the functions were left not depending on the type.

Fixes bug #14706, reported by Karen Huddleston.

Discussion: https://www.postgresql.org/message-id/20170614232259[email protected]

Ensure that CREATE STATISTICS statement is forwarded to remote nodes.

This is a new utility statement added in PG 10 and we should ensure that it
gets propagated to all the nodes in the cluster.

Reconcile nodes/*funcs.c with PostgreSQL 10 work.

The _equalTableFunc() omission of coltypmods has semantic significance,
but I did not track down resulting user-visible bugs, if any.  The other
changes are cosmetic only, affecting order.  catversion bump due to
readfuncs.c field order change.

Handle NextValueExpr node correctly at various places.

read/out functions for this node type were missing. So implement those
functions. In addition, the FQS code path was not recongnizing this new node
type correctly. Fix that too.

The ruleutils also missed ability to deparse this expression. For now we just
emit a DEFAULT clause while deparsing NextValueExpr and assume that the remote
node will do the necessary lookups to find the correct sequence and invoke
nextval() on the sequence.

Correct FormData_pg_attribute default values for xc_node_id

A new attribute got added to pg_attribute catalog in PG 10, we must update the
default FormData_pg_attribute for XL's xc_node_id system attribute with the
correct initial values.

Make configure check for IPC::Run when --enable-tap-tests is specified.

The TAP tests mostly don't work without IPC::Run, and the reason for
the failure is not immediately obvious from the error messages you get.
So teach configure to reject --enable-tap-tests unless IPC::Run exists.
Mostly this just involves adding ax_prog_perl_modules.m4 from the GNU
autoconf archives.

This was discussed last year, but we held off on the theory that we might
be switching to CMake soon.  That's evidently not happening for v10,
so let's absorb this now.

Eugene Kazakov and Michael Paquier

Discussion: https://postgr.es/m/56BDDC20.9020506@postgrespro.ru
Discussion: https://postgr.es/m/CAB7nPqRVKG_CR4Dy_AMfE6DXcr6F7ygy2goa2atJU4XkerDRUg@mail.gmail.com

Fix low-probability leaks of PGresult objects in the backend.

We had three occurrences of essentially the same coding pattern
wherein we tried to retrieve a query result from a libpq connection
without blocking.  In the case where PQconsumeInput failed (typically
indicating a lost connection), all three loops simply gave up and
returned, forgetting to clear any previously-collected PGresult
object.  Since those are malloc'd not palloc'd, the oversight results
in a process-lifespan memory leak.

One instance, in libpqwalreceiver, is of little significance because
the walreceiver process would just quit anyway if its connection fails.
But we might as well fix it.

The other two instances, in postgres_fdw, are somewhat more worrisome
because at least in principle the scenario could be repeated, allowing
the amount of memory leaked to build up to something worth worrying
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS
calls, as well as other calls that could potentially elog(ERROR),
providing another way to exit without having cleared the PGresult.
Here we need to add PG_TRY logic similar to what exists in quite a
few other places in postgres_fdw.

Coverity noted the libpqwalreceiver bug; I found the other two cases
by checking all calls of PQconsumeInput.

Back-patch to all supported versions as appropriate (9.2 lacks
postgres_fdw, so this is really quite unexciting for that branch).

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

doc:  remove mention of Windows junction points by pg_upgrade

pg_upgrade never used Windows junction points but instead always used
Windows hard links.

Reported-by: Adrian Klaver
Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8b09@aklaver.com

Backpatch-through: 9.3, where the mention first appeared

docs:  Fix pg_upgrade standby server upgrade docs

It was unsafe to instruct users to start/stop the server after
pg_upgrade was run but before the standby servers were rsync'ed.  The
new instructions avoid this.

RELEASE NOTES:  This fix should be mentioned in the minor release notes.

Reported-by: Dmitriy Sarafannikov and Sergey Burladyan
Discussion: https://postgr.es/m/[email protected]

Backpatch-through: 9.5, where standby server upgrade instructions first appeared

Rename function for consistency

Avoid using prefix "staext" when everything else uses "statext".

Author: Kyotaro HORIGUCHI
Discussion: https://postgr.es/m/20170615.140041.165731947[email protected]

psql: Improve display of "for all tables" publications

Show "All tables" property in \dRp and \dRp+.  Don't list tables for
such publications in \dRp+, since it's redundant and the list could be
very long.

Author: Masahiko Sawada <[email protected]>
Author: Jeff Janes <[email protected]>

Fix typo in code comment

Author: Daniel Gustafsson <[email protected]>

Remove unnecessary IPC::Run inclusion

This is no longer needed because the tests use PostgresNode.

Reported-by: Michael Paquier <[email protected]>

Show distribution information for partitioned tables too.

While using \d and associated commands in psql, we now check for partitioned
tables and fetch their distribution information too, just as regular tables.

Ensure transformCreateStmt allows partitioned table alongside regular table

While dealing with XL distribution, we check if the table is a regular table or
not. Since partitioned tables must get the same treatment as regular table as
far as distribution goes, we check and allow partitioned tables too.

Merge 'remotes/PGSQL/master' into xl10devel

Merge upstream master branch upto e800656d9a9b40b2f55afabe76354ab6d93353b3.
Code compiles and regression works ok (with lots and lots of failures though).

Use thread-specific storage for computing a snapshot.

We mustn't use a global variable since concurrent GTM threads might try to
compute a snapshot at the same time and may overwrite the information before a
thread can send the complete snapshot to the client. Chi Gao
<[email protected]> reported that this can cause infinite wait on the client
side because the client expects N bytes of data, but only receives (N - x)
bytes and it keeps waiting for remaining x bytes which the GTM never sends.
While we don't have a report, it's obvious that it can also go wrong in the
other direction.

We fix this by using a thread-specific storage which ensures that the snapshot
cannot be changed while it's being sent to the client.

Report, analysis and fix by Chi Gao <[email protected]>. Some minor
editorialisation by me.

Backpatched to XL9_5_STABLE

Fix couple of merge issues in sequence handling code

At one place we missed out an END_CRIT_SECTION(), so put that back. Also,
GetGlobalSeqName() was using a wrong relation while generating the sequence
name. This was caused as a result of the merge which introduced a new code
block in between, thus setting the local variable referring the sequence
relation to the pg_catalog.pg_sequence relation.

Check for SQLValueFunction node in shippability walker

Pass correct information to the executor.

While executing RemoteSubplan we'd accidentally set "execute_once" to true,
even though that wasn't appropriate. Correct that mistake and always use the
information in the Portal to decide whether to execute once or more.

Check for non-utility commands in PlannedStmt

Starting PG 10, even utility statements are wrapped in a PlannedStmt. So we
must ensure that we are dealing with non-utility statements before trying to
look into the planTree because it won't be set for utility statements.

Take into account the fact that pg_parse_query() returns a list of RawStmt

Starting PG 10, pg_parse_query() returns a list of RawStmt unlike a list of
parse trees. The actual parse tree is now available as RawStmt->stmt. So we
must look into the correct place to check if the supplied query is one of the
special statements such as VACUUM, CLUSTER or CREATE INDEX statement, which
needs special handling.

Read/write OID fields in SQLValueFunction node correctly.

We must convert OID into a qualified name before sending it down to the remote
datanode and do the reverse on the remote end. This is a new node type added in
PG 10 and hence support was missing.

Use Plan/Scan read functions from PG 10 core.

PG 10 now has facilities to read Plan and Scan nodes. So we don't need our own
implementation for that. Makes the code a bit shorter and cleaner too.

Avoid using "tapeset" in XL-specific tuplesort code.

"tapeset" may not be setup when we are using tuplesort to merge tuples from
remote connections. So avoid referencing tapeset members.

Fix typo in PostgreSQL 10.0 release note.

Patch by Yugo Nagata.

Fix document bug regarding read only transactions.

It was explained that read only transactions (not in standby) allow to
update sequences. This had been wrong since the commit:
05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7

Discussion: https://www.postgresql.org/message-id/20170614.110826.425627939780392324.t-ishii%40sraoss.co.jp

Fix problems related to RangeTblEntry members enrname and enrtuples.

Commit 18ce3a4ab22d2984f8540ab480979c851dae5338 failed to update
the comments in parsenodes.h for the new members, and made only
incomplete updates to src/backend/nodes

Thomas Munro, per a report from Noah Misch.

Discussion: http://postgr.es/m/20170611062525[email protected]

Don't force-assign transaction id when exporting a snapshot.

Previously we required every exported transaction to have an xid
assigned. That was used to check that the exporting transaction is
still running, which in turn is needed to guarantee that that
necessary rows haven't been removed in between exporting and importing
the snapshot.

The exported xid caused unnecessary problems with logical decoding,
because slot creation has to wait for all concurrent xid to finish,
which in turn serializes concurrent slot creation.   It also
prohibited snapshots to be exported on hot-standby replicas.

Instead export the virtual transactionid, which avoids the unnecessary
serialization and the inability to export snapshots on standbys. This
changes the file name of the exported snapshot, but since we never
documented what that one means, that seems ok.

Author: Petr Jelinek, slightly editorialized by me
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/f598b4b8-8cd7-0d54-0939-adda763d8c34@2ndquadrant.com

Use DEFACLOBJ_ macros in error message instead of hardcoding

Add missing serial comma

doc: Whitespace fixes in man pages

Teach predtest.c about CHECK clauses to fix partitioning bugs.

In a CHECK clause, a null result means true, whereas in a WHERE clause
it means false.  predtest.c provided different functions depending on
which set of semantics applied to the predicate being proved, but had
no option to control what a null meant in the clauses provided as
axioms.  Add one.

Use that in the partitioning code when figuring out whether the
validation scan on a new partition can be skipped.  Rip out the
old logic that attempted (not very successfully) to compensate
for the absence of the necessary support in predtest.c.

Ashutosh Bapat and Robert Haas, reviewed by Amit Langote and
incorporating feedback from Tom Lane.

Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com

Improve release note text about set-returning-function changes.

Paul Ramsey griped about this awhile ago, but I'd been holding fire
on changing it until we settled what to do about the CASE/COALESCE
issue.

Discussion: https://postgr.es/m/CACowWR0AMyUt5fwtvuDqWyYNdp-hQJj9XqSxJR6YM9sKWov=_w@mail.gmail.com

Avoid bogus TwoPhaseState locking sequences

The optimized code in 728bd991c3c4 contains a few invalid locking
sequences.  To wit, the original code would try to acquire an lwlock
that it already holds.  Avoid this by moving lock acquisitions to
higher-level code, and install appropriate assertions in low-level that
the correct mode is held.

Authors: Michael Paquier, Álvaro Herrera
Reported-By: chuanting wang
Bug: #14680
Discussion: https://postgr.es/m/20170531033228[email protected]

Put documentation of options and commands in more alphabetical order

Fix no-longer-valid shortcuts in expression_returns_set().

expression_returns_set() used to short-circuit its recursion upon
seeing certain node types, such as DistinctExpr, that it knew the
executor did not support set-valued arguments for.  That was never
inherent, though, just a reflection of laziness in execQual.c.
With the new implementation of SRFs there is no reason to think
that any scalar-valued expression node could not have a set-valued
subexpression, except for AggRefs and WindowFuncs where we know there
is a parser check rejecting it.  And indeed, the shortcut causes
unexpected failures for cases such as a SRF underneath DistinctExpr,
because the planner stops looking for SRFs too soon.

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

Fix violations of CatalogTupleInsert/Update/Delete abstraction.

In commits 2f5c9d9c9 and ab0289651 we invented an abstraction layer
to insulate catalog manipulations from direct heap update calls.
But evidently some patches that hadn't landed in-tree at that point
didn't get the memo completely.  Fix a couple of direct calls to
simple_heap_delete to use CatalogTupleDelete instead; these appear
to have been added in commits 7c4f52409 and 7b504eb28.  This change is
purely cosmetic ATM, but there's no point in having an abstraction layer
if we allow random code to break it.

Masahiko Sawada and Tom Lane

Discussion: https://postgr.es/m/CAD21AoDOPRSVcwbnCN3Y1n_68ATyTspsU6=ygtHz_uY0VcdZ8A@mail.gmail.com

Teach PL/pgSQL about partitioned tables.

Table partitioning, introduced in commit f0e44751d7, added a new
relkind - RELKIND_PARTITIONED_TABLE. Update a couple of places in
PL/pgSQL to handle it. Specifically plpgsql_parse_cwordtype() and
build_row_from_class() needed updating in order to make table%ROWTYPE
and table.col%TYPE work for partitioned tables.

Dean Rasheed, reviewed by Amit Langote.

Discussion: https://postgr.es/m/CAEZATCUnNOKN8sLML9jUzxecALWpEXK3a3W7y0PgFR4%2Buhgc%3Dg%40mail.gmail.com

Teach RemoveRoleFromObjectPolicy() about partitioned tables.

Table partitioning, introduced in commit f0e44751d7, added a new
relkind - RELKIND_PARTITIONED_TABLE. Update
RemoveRoleFromObjectPolicy() to handle it, otherwise DROP OWNED BY
will fail if the role has any RLS policies referring to partitioned
tables.

Dean Rasheed, reviewed by Amit Langote.

Discussion: https://postgr.es/m/CAEZATCUnNOKN8sLML9jUzxecALWpEXK3a3W7y0PgFR4%2Buhgc%3Dg%40mail.gmail.com

Ensure slab allocator is initialised correctly.

XL uses tuplesort facilities to merge incoming tuples from the datanode
connections. We'd missed out a few things during the merge and this patch
attempts to fix that.

It's not clear if we have addressed all problems in this area, since the code
has been heavily modified in PG10. But this patch at the very least allows
further testing.

Ensure that pgstat knowns about XL background processes.

XL has two background processes of its own, the cluster monitor process and the
pooler process. This patch ensures that pgstat is aware of these additional
built-in background processes.

Revert "Handle multi-command queries correctly inside SQL as well as plpgsql functions."

This reverts commit 9ddddcb8d51fd640f59401ea9bc335d08bf5a23c.  This commit uses
the facilities created by 455ff923454e78d80b77639a381db9b05c776577, which
itself has been now reverted.

Revert "Handle multi-command SQL strings correctly even when there are 'null' sql"

This reverts commit df13f58003d119162d9a1450ced06048e5992b67. This commit uses
the facilities created by 455ff923454e78d80b77639a381db9b05c776577, which
itself has been now reverted.

Revert "Collect and return query substrings corresponding to each SQL statement"

This reverts commit 455ff923454e78d80b77639a381db9b05c776577. Core Postgres has
now added support for extracting query string for each command in a
multi-command SQL. So we can use that facility instead of cooking up something
on our own.

Merge from PG master upto d5cb3bab564e0927ffac7c8729eacf181a12dd40

This is the result of the "git merge remotes/PGSQL/master" upto the said commit
point. We have done some basic analysis, fixed compilation problems etc, but
bulk of the logical problems in conflict resolution etc will be handled by
subsequent commits.

Disallow set-returning functions inside CASE or COALESCE.

When we reimplemented SRFs in commit 69f4b9c85, our initial choice was
to allow the behavior to vary from historical practice in cases where a
SRF call appeared within a conditional-execution construct (currently,
only CASE or COALESCE).  But that was controversial to begin with, and
subsequent discussion has resulted in a consensus that it's better to
throw an error instead of executing the query differently from before,
so long as we can provide a reasonably clear error message and a way to
rewrite the query.

Hence, add a parser mechanism to allow detection of such cases during
parse analysis.  The mechanism just requires storing, in the ParseState,
a pointer to the set-returning FuncExpr or OpExpr most recently emitted
by parse analysis.  Then the parsing functions for CASE and COALESCE can
detect the presence of a SRF in their arguments by noting whether this
pointer changes while analyzing their arguments.  Furthermore, if it does,
it provides a suitable error cursor location for the complaint.  (This
means that if there's more than one SRF in the arguments, the error will
point at the last one to be analyzed not the first.  While connoisseurs of
parsing behavior might find that odd, it's unlikely the average user would
ever notice.)

While at it, we can also provide more specific error messages than before
about some pre-existing restrictions, such as no-SRFs-within-aggregates.
Also, reject at parse time cases where a NULLIF or IS DISTINCT FROM
construct would need to return a set.  We've never supported that, but the
restriction is depended on in more subtle ways now, so it seems wise to
detect it at the start.

Also, provide some documentation about how to rewrite a SRF-within-CASE
query using a custom wrapper SRF.

It turns out that the information_schema.user_mapping_options view
contained an instance of exactly the behavior we're now forbidding; but
rewriting it makes it more clear and safer too.

initdb forced because of user_mapping_options change.

Patch by me, with error message suggestions from Alvaro Herrera and
Andres Freund, pursuant to a complaint from Regina Obe.

Discussion: https://postgr.es/m/000001d2d5de$d8d66170$8a832450[email protected]

doc: Update example version numbers in pg_upgrade documentation

The exact numbers don't matter, since they are examples, but it was
looking quite dated.

For the target version, we now automatically substitute the current
major version.  The updated example source version should be good for a
couple of years.

psql: Use more consistent capitalization of some output headings

Re-run pgindent.

This is just to have a clean base state for testing of Piotr Stefaniak's
latest version of FreeBSD indent.  I fixed up a couple of places where
pgindent would have changed format not-nicely.  perltidy not included.

Discussion: https://postgr.es/m/VI1PR03MB119959F4B65F000CA7CD9F6BF2CC0@VI1PR03MB1199.eurprd03.prod.outlook.com

Always initialize PartitionBoundInfoData's null_index.

This doesn't actually matter at present, because the current code
never consults null_index for range partitions.  However, leaving
it uninitialized is still a bad idea, so let's not do that.

Amul Sul, reviewed by Ashutosh Bapat

Discussion: http://postgr.es/m/CAAJ_b94AkEzcx+12ySCnbMDX7=UdF4BjnoBGfMQbB0RNSTo3Ng@mail.gmail.com

Teach relation_is_updatable() about partitioned tables.

Table partitioning, introduced in commit f0e44751d7, added a new
relkind - RELKIND_PARTITIONED_TABLE. Update relation_is_updatable() to
handle it. Specifically, partitioned tables and simple views built on
top of them are updatable.

This affects the SQL-callable functions pg_relation_is_updatable() and
pg_column_is_updatable(), and the views information_schema.views and
information_schema.columns.

Dean Rasheed, reviewed by Ashutosh Bapat.

Discussion: https://postgr.es/m/CAEZATCXnbiFkMXgF4Ez1pmM2c-tS1z33bSq7OGbw7QQhHov%2B6Q%40mail.gmail.com

libpq: Message style improvements

Fix failure to remove dependencies when a partition is detached.

Otherwise, dropping the partitioned table will automatically drop
any previously-detached children, which would be unfortunate.

Ashutosh Bapat and Rahila Syed, reviewed by Amit Langote and by me.

Discussion: http://postgr.es/m/CAFjFpRdOwHuGj45i25iLQ4QituA0uH6RuLX1h5deD4KBZJ25yg@mail.gmail.com

doc: Fix typo

Author: Julien Rouhaud <[email protected]>

In initdb, defend against assignment of NULL values to not-null columns.

Previously, you could write _null_ in a BKI DATA line for a column that's
supposed to be NOT NULL and initdb would let it pass, probably breaking
subsequent accesses to the row.  No doubt the original coding overlooked
this simple sanity check because in the beginning we didn't have any way
to mark catalog columns NOT NULL at initdb time.

Fix typo

Author: Masahiko Sawada <[email protected]>

Improve code comments

Author: Erik Rijkers <[email protected]>

Use correct ICU path for Windows 32 vs. 64 bit

Author: Ashutosh Sharma <[email protected]>

Fix collprovider of predefined collations

An earlier version of the patch had collprovider as an integer and thus
set these to 0, but the correct setting is now null.

pg_dump: Allow dumping default collation

This will not work on restore, but it will allow dumping out pg_catalog
for research and documentation.

Reported-by: Neil Anderson <[email protected]>
Bug: #14701

Prevent copying default collation

This will not have the desired effect and might lead to crashes when the
copied collation is used.

Reported-by: Tom Lane <[email protected]>

Fix confusion about number of subplans in partitioned INSERT setup.

ExecInitModifyTable() thought there was a plan per partition, but no,
there's only one.  The problem had escaped detection so far because there
would only be visible misbehavior if there were a SubPlan (not an InitPlan)
in the quals being duplicated for each partition.  However, valgrind
detected a bogus memory access in test cases added by commit 4f7a95be2,
and investigation of that led to discovery of the bug.  The additional
test case added here crashes without the patch.

Patch by Amit Langote, test case by me.

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

pg_dump: Fix harmless type mixup

doc: Update external PL list

Add PL/Lua, PL/v8.

Remove stale/unmaintained PL/PHP, PL/Py, PL/Ruby, PL/Scheme.

Reported-by: Adam Sah <[email protected]>

Assert that we don't invent relfilenodes or type OIDs in binary upgrade.

During pg_upgrade's restore run, all relfilenode choices should be
overridden by commands in the dump script.  If we ever find ourselves
choosing a relfilenode in the ordinary way, someone blew it.  Likewise for
pg_type OIDs.  Since pg_upgrade might well succeed anyway, if there happens
not to be a conflict during the regression test run, we need assertions
here to keep us on the straight and narrow.

We might someday be able to remove the assertion in GetNewRelFileNode,
if pg_upgrade is rewritten to remove its assumption that old and new
relfilenodes always match.  But it's hard to see how to get rid of the
pg_type OID constraint, since those OIDs are embedded in user tables
in some cases.

Back-patch as far as 9.5, because of the risk of back-patches breaking
something here even if it works in HEAD.  I'd prefer to go back further,
but 9.4 fails both assertions due to get_rel_infos()'s use of a temporary
table.  We can't use the later-branch solution of a CTE for compatibility
reasons (cf commit 5d16332e9), and it doesn't seem worth inventing some
other way to do the query.  (I did check, by dint of changing the Asserts
to elog(WARNING), that there are no other cases of unwanted OID assignments
during 9.4's regression test run.)

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

Fix ALTER SEQUENCE OWNED BY to not rewrite the sequence relation.

It's not necessary for it to do that, since OWNED BY requires only ordinary
catalog updates and doesn't affect future sequence values.  And pg_upgrade
needs to use OWNED BY without having it change the sequence's relfilenode.
Commit 3d79013b9 broke this by making all forms of ALTER SEQUENCE change
the relfilenode; that seems to be the explanation for the hard-to-reproduce
buildfarm failures we've been seeing since then.

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

doc: Update information_schema documentation for identity columns

This was apparently forgotten in the original patch.

Add ICU_CFLAGS to global CPPFLAGS

The original code only added ICU_CFLAGS to the backend build.  But it is
also needed for building external modules that include pg_locale.h.  So
add it to the global CPPFLAGS.  (This is only relevant if ICU is not in
a compiler default path, so it apparently hasn't bitten many.)

Remove "synchronized table states" notice message

It appears to be more confusing than useful.

Reported-by: Jeff Janes <[email protected]>

Add MSVC build system support for ICU

Author: Ashutosh Sharma <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>

Fix build of ICU support in Windows

and also any platform that does not have locale_t but enabled ICU.

Author: Ashutosh Sharma <[email protected]>

Trim trailing whitespace

Stop table sync workers when subscription relation entry is removed

When a table sync worker is in waiting state and the subscription table
entry is removed because of a concurrent subscription refresh, the
worker could be left orphaned.  To avoid that, explicitly stop the
worker when the pg_subscription_rel entry is removed.

Reported-by: Masahiko Sawada <[email protected]>

Fix ALTER TABLE doc examples.

Patch by Yugo Nagata <[email protected]>.  Confirmed by Amit
Langote, who is the original author of the document part.

Handle unqualified SEQUENCE NAME options properly in parse_utilcmd.c.

generateSerialExtraStmts() was sloppy about handling the case where
SEQUENCE NAME is given with a not-schema-qualified name.  It was generating
a CreateSeqStmt with an unqualified sequence name, and an AlterSeqStmt
whose "owned_by" DefElem contained a T_String Value with a null string
pointer in the schema-name position.  The generated nextval() argument was
also underqualified.  This accidentally failed to fail at runtime, but only
so long as the current default creation namespace at runtime is the right
namespace.  That's bogus; the parse-time transformation is supposed to be
inserting the right schema name in all cases, so as to avoid any possible
skew in that selection.  I'm not sure this could fail in pg_dump's usage,
but it's still wrong; we have had real bugs in this area before adopting
the policy that parse_utilcmd.c should generate only fully-qualified
auxiliary commands.  A slightly lesser problem, which is what led me to
notice this in the first place, is that pprint() dumped core on the
AlterSeqStmt because of the bogus T_String.

Noted while poking into the open problem with ALTER SEQUENCE breaking
pg_upgrade.

Apply RLS policies to partitioned tables.

The new partitioned table capability added a new relkind, namely
RELKIND_PARTITIONED_TABLE. Update fireRIRrules() to apply RLS
policies on RELKIND_PARTITIONED_TABLE as it does RELKIND_RELATION.

In addition, add RLS regression test coverage for partitioned tables.

Issue raised by Fakhroutdinov Evgenievich and patch by Mike Palmiotto.
Regression test editorializing by me.

Discussion: https://postgr.es/m/flat/20170601065959[email protected]

Restrict subplan nodes even for equal distributions

Many regression tests were failing because the expected plan contains

    Remote Subquery Scan on all (datanode_1)

but we were producing

    Remote Subquery Scan on any (datanode_1,datanode_2)

Both those plans are in fact valid (at least on replicated tables).
The difference is that in the first case the restriction was computed
in adjust_subplan_distribution() while in the second case this did not
happen (and instead will happen at execution time).

The restriction is not applied because adjust_subplan_distribution()
contains this condition

    if (subd && !equal(subd, pathd))
    {
        ... restrict execution nodes ...
    }

In Postgres-XL 9.6 the two distributions happen to be equal in some
cases where where that was not the case in Postgres-XL 9.5. It's not
entirely clear why this happens (it seems to be another consequence
of the upper-planner pathification), but the consequence is that the
restriction code is skipped.

Removing the equal() call from the condition fixes all the regression
failures caused by plans switching between any/all restrictions. In
fact, this fixes all remaining regressions failures in five regression
suites: create_view, subselect, aggregates, rangefuncs, xc_having.

In the future, we will probably pathify adjust_subplan_distribution(),
i.e. we'll probably get rid of it entirely and compute the restriction
either when constructing the path or possibly defer it until execution
time. Before the upper-planner pathification this was not possible.

Take PROVE_FLAGS from the command line but not the environment

This reverts commit 56b6ef893fee9e9bf47d927a02f4d1ea911f4d9c and instead
makes vcregress.pl parse out PROVE_FLAGS from a command line argument
when doing a TAP test, thus making it consistent with the makefile
treatment.

Discussion: https://postgr.es/m/c26a7416-2fb9-34ab-7991-618c922f896e%402ndquadrant.com

Backpatch to 9.4 like previous patch.