Ensure config changes caused by functions are rolled back correctly.

When a function body has SET clauses attached to it, the function
validation/execution reflects those config changes locally as well as on the
remote nodes. But we were failing to restore the old values back when the
command ends. This had gone unnoticed so far for the lack of any test case
exercising this code. Note that there were existing test cases in this area,
but the bug got unmasked only after we added a temporary table in the session.
When a temporary table is accessed in a session, we don't reset the session at
the end of the transaction and hence the issue surfaced.

This was causing failure in a new test added in the 'rules' test. This patch
fixes that.

Accept regression diffs in 'object_address' test case.

The differences are caused by our lack of support for CREATE
SUBSCRIPTION/PUBLICATION

Accept regression diffs in 'portal' test case.

One change relates to the addition of Remote Subplan node and the other relates
to our lack of support for WHERE CURRENT OF

Fix an oversight in c8a42a0726911b737837d6763707c7d14d9a2987

Well spotted by Virendra Kumar

Some edits to a TAP test

Minor refactoring of the code to send down SET options

Add a TAP test to do sanity tests post addition of coordinators/datanodes.

Its a very simplistic test right now, but hopefully we can extend this further
in the coming time.

Use read-write transaction to dump a database

In XL we use nextval() to get a consistent value of a sequence since different
nodes may have stale view of the sequence and hence we must obtain a value from
the GTM. Calling nextval() though requires us to execute the transaction in
read-write mode. So we do that. It shouldn't be a big deal since pg_dump is
very careful about only reading from the database (it was only recently the
transaction was made read-only). More to the point, in XL we'd never used
read-only transaction while dumping a database, but by default direct
connection to a datanode are treated as read-only transaction and hence merely
removing READ ONLY transaction attribute wasn't enough. We had to explicitly
mark it READ WRITE to override the default datanode behaviour.

Per report by Virendra Kumar

Accept regression diff in 'xml' test case casued by merge issue

Accept regression diffs arising due to lack of FDW support

Accept regression diffs arising due to lack of trigger support

Accept expected output diffs pertaining to Remote Subplan addition

All these test caes were failing because of Remote Subplan nodes in the explain
output.

Accept regression diffs in 'inherit' test case

We're simply adding Remote Subplan nodes to the query plans

Accept regression diff in 'create_table' test

We're simply printing the distribution info too

Amend and accept regression diffs in 'insert' test case

We don't support triggers and hence the do-nothing trigger doesn't have the
desired effect in XL. As a result, the inserts are not skipped in XL (while
they are skipped because the before-row trigger returns nothing).  Also we
expect columns to be in the same order for partitions. So make those changes
too.

Ensure datanode WAL directory changes are reflected on failover.

We'd failed to take into account the changes to WAL dirs in pgxc_ctl.conf upon
failover. This would later cause issues while reading the conf file.

Per report and patch by Virendra Kumar

Merge tag 'REL_10_5' into XL_10_STABLE

Change some expected output files to reflect change in error message

This accounts for the change in the error message introduced in
305ad92ae05a7a367501be3f68cde9ff9f827622.

Leverage binary-upgrade facility of pg_dump

While adding a new coordinator or a datanode, we take a schema dump of an
existing node and restore it on the new node. This has some problems,
especially while restoring tables with dropped columns and different column
ordering. The new node won't restore the dropped columns and may recreate
columns in different ordering, for inheritted tables for example. This then
leads to issues during query execution.

We now leverage binary-upgrade dump facility available in pg_dump/pg_restore.
While XL is not very sensitive to OID preservation across nodes, we do care
about column ordering. So binary-upgrade's OID preservation facility is of not
great interest to us, but it shouldn't harm also.

Also ensure that while restoring sequence states, we don't force update the GTM
state.

A tap test is added to check the node addition this way.

The original report came from Krzysztof Nienartowicz. Patch and further work by
me.

Correct error message to use word "distributed" instead of "partitioned".

Per report by Pallavi Sontakke

Add test for Set Returning Functions

Fixes #204

Ensure consistent output in the 'select_views' test case

We added ORDER BY clause to the query, but that returns different ordering
depending on the LC_COLLATE setting on a given machine. So enforce the correct
ordering by specifying the desired collation in the query itself.

Correct date in the release notes

Restamp Postgres-XL 10r1beta1 correctly this time.

Correct some typos in the release notes

Stamp Postgres-XL 10r1beta1

Make COPYRIGHT changes

Some updates to the release notes draft

Fix couple of compiler warnings

Fix some more compiler warnings

Remove some unused variables, fix compiler warnings

Fix a few compiler warnings

Write draft release notes for Postgres-XL 10r1beta1

Adding missing documentation for pgxl_remote_fetch_size

Initialise a variable correctly.

This was leading to unexpected/unexplained crashes in the cluster monitor
process. Per reprot by Hengbing

Disable FQS for explicit cursor queries.

The FQS mechanism is not currently handling cursors well as seen by failures in
the 'combocid' test case. The regular planner handles it well though. So for
now disable FQS for such queries.

Also remove the restriction that TID scan cannot be performed by non-FQS
queries. Regression does not throw up any errors. So remove the restriction
unless we see a counter example.

Tomas Vondra commented that this works fine in XL 9.5, so most likely we might
be failing to send a proper snapshot to the datanodes. Further investigations
required.

Accept regression diffs in 'xml' test case

They are related to our lack of support for subtransactions (exception blocks)
and adding Remote Subquery Scan plan nodes.

Test ALTER TABLE.. ADD PRIMARY KEY

Ensure that this sets columns NOT NULL on all child tables on all nodes

test ALTER TYPE.. RENAME VALUE

Run ANALYZE (COORDINATOR) on remote coordinators iff running outside a txn
block

We'd seen some distributed deadlocks when ANALYZE (COORDINATOR) is run on
remote coordinators, in parallel with VACUUM FULL on catalog tables. The
investigations so far indicate that the auxilliary datanode connections from
the other coordinators can lead to a distributed deadlock as the connections
from the originating coordinator still have the transaction open.

We now restrict remote analyze only when we are not running inside a user
transaction block. This allows us to commit the first transaction and then
start a new transaction to run ANALYZE (COORDINATOR) on the remote
coordinators, thus avoiding the distributed deadlock.

Per report from Pallavi Sontakke and lots of analysis by me, which may not
still be sufficient.

Remove a problem test from 'inherit' test case

There is a problem with reading an anonymous record type, resulting in an error
such as "ERROR:  input of anonymous composite types is not implemented".

This is an existing issue affecting even XL 9.5, but was masked so far by lack
of testing and also because we inadvertently accepted wrong output in XL 9.5.
For now, move the case to xl_known_bugs and open an issue to track this
potential long standing bug.

Move failing tests from 'with' to 'xl_known_bugs'

There are two remaining failures in the 'with' test case. Both of these bugs
exist in XL 9.5 too and hence moving them to the xl_known_bugs test case. We
have issues open for these bugs.

Adjust 'limit' test case to avoid regression failures.

There are two known problems in the test case.

1. When nextval() is pushed down to the remote nodes, the coordinator session
won't have seen a nextval() invokation and hence a subsequent currval() will
throw an ERROR or return a stale value.

2. When nextval() is pushed down to the remote nodes and a set of rows are
fetched (either ordered or otherwise), the results may be somewhat inconsistent
because each node will run nextval() concurrently and hence the ordering will
change depending on who runs when.

For now, change the queries to force nextval() evaluation on the coordinator.
Also move the original test cases to xl_known_bugs test case and we also have
an internal issue open to track this problem.

Fetch sn_xcnt just once to ensure consistent msg

We're seeing some reports when fetching snapshot from the GTM hangs forever on
the client side, waiting for data which never arrives. One theory is that the
snapshot->sn_xcnt value changes while sending snapshot from the GTM, thus
causing a mismatch between what the server sends and what the client expects.
We fixed a similar problem in 1078b079d5476e3447bd5268b317eacb4c455f5d, but may
be it's not complete. Put in this experimental patch (which can't make things
any worse for sure) while we also investigate other bugs in that area.

Fix problems associated with globalXmin tracking by ClusterMonitor

The very first report by the cluster monitor may be discarded by the GTM if the
reporting xmin has fallen far behind GTM's view. This leads to the globalXmin
value remaining Invalid in the shared memory state, as tracked by the
ClusterMonitor. ClusterMonitor process usually naps for CLUSTER_MONITOR_NAPTIME
(default 5s) between two successive reporting. But discard that during the
bootup process and report the xmin a bit more aggressively. This should in all
likelihood set the globalXmin correctly, before the regular backends start
processing.

The other major problem with the current code was that when the globalXmin
tracked in the shared memory state is Invalid, the callers were using
FirstNormalXid as the globalXmin. This could be disastrous especially when XID
counter has wrapped around. We could accidentally remove visible rows by using
a wrong value of globalXmin. We now fix that by computing the globalXmin using
the local state (just like we would have computed globalXmin in vanilla PG).
This should ensure that we never use a wrong or a newer value for globalXmin
than what is allowed.

Accept regression diff in txid test case resulting from the fix. The new
expected output actually matches with what upstream produces.

Per report by Hengbing and investigations/fix by me.

Use correct format specifier for transaction ids

Remove duplicate (and unused) declaration of XidStatus

Force restart cluster monitor process if the GTM restarts

If GTM loses node registration information and returns
GTM_ERRCODE_NODE_NOT_REGISTERED to the coordinator/datanode, restart the
cluster monitor process (by simply exiting with exit code 0). This would ensure
that the cluster monitor re-registers with the GTM and start cleanly.

Per report by Virendra Kumar

Ensure pgxc_node_str returns the result in correct format

Per report from Krzysztof Nienartowicz, this broke the pgxc_clean command on
XL10.

Allow minimum value of pgxl_remote_fetch_size to zero

This is an experimental work. By setting pgxl_remote_fetch_size to 0, user can
fetch all rows at once from the remote side (instead of fetching a small number
at a time, thus giving the node to produce more rows as the previous set is
consumed). While fetching all rows at once is not very useful, it allows us to
circumvent PostgreSQL's limitation of not supporting parallel queries unless a
Portal is run once and to the end.

We do see hangs in regression while running with PGOPTIONS set to "-c
force_parallel_mode=on -c pgxl_remote_fetch_size=0", so there are issues that
need to be addressed. Also, it doesn't seem quite possible for users to
dynamically set pgxl_remote_fetch_size to enforce parallel query. So this is an
experimental feature that we don't expect users to heavily use, just yet.

Ensure parallelModeNeeded flag is sent down to the remote node.

This still does not solve the problem that the datanodes don't make use of
parallel queries during distributed execution (they work OK if queries are
FQSed). That's because PostgreSQL does not support parallel queries when a
portal is used to fetch only a part of the result set. We need separate patches
to either fix or work-around that.

Accept some more regression diffs in inherit.out

We changed one test case to use HASH distribution so that a primary key can be
defined. Another diff turned out to be a change from the upstream.

Fix an assertion failure

Ensure that RemoteSubplan is marked parallel unsafe.

We can't support multiple backends running RemoteSubplan in parallel. So block
that. In fact, we'd already done so by setting parallel_safe to false while
creating the path, but there is another code path which builds the plan node
directly and we'd missed that.

Fix an oversight in 32025718755c4bbf100563fdc88e96225fc1b250

In passing, add test cases and fix other issues around fetching table sizes
from remote nodes. For example, temp handling and names requiring quoting was
broken for long too.

Per report by Virendra Kumar and further tests by me.

Do not pushdown aggregates with SRFs in the targetlist

Some minor changes to tsrf test case

We don't support SRF in VALUES clause yet. So make some minor adjustments to
the test case.

Accept regression diffs in the sequence test case

These diffs are on the account of differences in the way we handle WAL logging
and sequences on the coordinator. There is scope for improvement here from
usability perspective, but these are not regressions from the past behaviour.

Make improvements to sequence handling

We were pre-maturely checking for maximum and minimum values, thus throwing an
error when the maximum/minimum was still farther by one count. Fix that.
Improve the GTM error message by including the sequence name and the max/min
value reached. This though slightly changes the end user error message because
we also include database and schema in the sequence name at the GTM.

Make some changes to the way sequence is WAL logged. This is still not entirely
correct since we log every time a value is fetched from the GTM. But then WAL
logging is not strictly required in XL because sequence values are managed at
the GTM. In the old code, we were not WAL logging at all (though the code
existed and it was a bit confusing)

The sequence tuple is still not maintained correctly at the coordinator because
it may not know about the sequence values fetched and consumed by the
datanodes. But that's an existing problem and we should look at that
separately.

Ensure table name is schema qualified while running remote ANALYZE

While sending down ANALYZE (COORDINATOR) command to the remote coordinator, we
must ensure that the table name is properly schema qualified. Also add a few
tests to confirm that this works as expected in various scenarios.

Per report by Virendra Kumar.

Automatically trigger ANALYZE (COORDINATOR) on remote coordinators

One of the long standing problems in multi-coordinator setup is that when a
table is either manually ANALYZEd or auto-analyzed on a coordinator, the other
coordinators don't update their planner statistics automatically. This is even
a bigger problem with auto-analyze because a coordinator which is not involved
in any DMLs, may not be even aware about the changes to the table and hence it
will not pick up the table for auto-analyze, thus often generating very poor
query plans.

We now fix that by automatically running ANALYZE (COORDINATOR) command on the
remote coordinators when a table is either manually or automatically analyzed
on one coordinator. ANALYZE (COORDINATOR) does not force a ANALYZE on the
datanodes, but only rebuilts coordinator side stats using the current stats
available on the datanodes.

One problem with running ANALYZE on the remote coordinators in auto-analyze
process is that if one of the coordinators is down or not reachable, then it
will fail. This seems a bit too harsh because the worst that can happen is that
the unreachably coordinator will be left with stale stats. But that seems
better than letting auto-analyze fail on a running coordinator. We address this
by introducing a new mechanism by which a coordinator can execute a
command/query only on the currently available remote coordinators. We consult
the health-map to decide which coordinators are currently reachable. Since the
health-map itself can be stale for some short duration, there is a risk that
auto-analyze may still fail. But it shouldn't fail forever because the node
will be skipped next time.

Fetch minmxid from remote nodes and compute local value

This was a TODO for quite sometime now. Just like we fetch relfrozenxid from
the remote nodes and compute a value at the coordinator, we now do the same for
multi-xid too.

Remove some dead/commented code

Correctly track XID obtained by autovac as one from the GTM

We were observing that a transaction started by the autovac process was left
open on the GTM, thus holding back xmin. This must have been a regression after
recent changes to track autocommit and regular transactions. We now correctly
track and close such transactions on the GTM.

Add a test to do sanity check at the end

Right now it only contains a test to check replicated tables and confirm that
all nodes have the same number of rows. More to be added later.

Stamp 10.5.

Translation updates

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 3463878fc340cb1436153b18a300f8cfdcb12adb

Last-minute updates for release notes.

Security: CVE-2018-10915, CVE-2018-10925

Fix failure to reset libpq's state fully between connection attempts.

The logic in PQconnectPoll() did not take care to ensure that all of
a PGconn's internal state variables were reset before trying a new
connection attempt.  If we got far enough in the connection sequence
to have changed any of these variables, and then decided to try a new
server address or server name, the new connection might be completed
with some state that really only applied to the failed connection.

While this has assorted bad consequences, the only one that is clearly
a security issue is that password_needed didn't get reset, so that
if the first server asked for a password and the second didn't,
PQconnectionUsedPassword() would return an incorrect result.  This
could be leveraged by unprivileged users of dblink or postgres_fdw
to allow them to use server-side login credentials that they should
not be able to use.

Other notable problems include the possibility of forcing a v2-protocol
connection to a server capable of supporting v3, or overriding
"sslmode=prefer" to cause a non-encrypted connection to a server that
would have accepted an encrypted one.  Those are certainly bugs but
it's harder to paint them as security problems in themselves.  However,
forcing a v2-protocol connection could result in libpq having a wrong
idea of the server's standard_conforming_strings setting, which opens
the door to SQL-injection attacks.  The extent to which that's actually
a problem, given the prerequisite that the attacker needs control of
the client's connection parameters, is unclear.

These problems have existed for a long time, but became more easily
exploitable in v10, both because it introduced easy ways to force libpq
to abandon a connection attempt at a late stage and then try another one
(rather than just giving up), and because it provided an easy way to
specify multiple target hosts.

Fix by rearranging PQconnectPoll's state machine to provide centralized
places to reset state properly when moving to a new target host or when
dropping and retrying a connection to the same host.

Tom Lane, reviewed by Noah Misch.  Our thanks to Andrew Krasichkov
for finding and reporting the problem.

Security: CVE-2018-10915

Adjust error message

Makes it look more similar to other ones, and avoids the need for
pluralization.

Release notes for 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.

Doc: fix incorrectly stated argument list for pgcrypto's hmac() function.

The bytea variant takes (bytea, bytea, text).
Per unsigned report.

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

Fix INSERT ON CONFLICT UPDATE through a view that isn't just SELECT *.

When expanding an updatable view that is an INSERT's target, the rewriter
failed to rewrite Vars in the ON CONFLICT UPDATE clause.  This accidentally
worked if the view was just "SELECT * FROM ...", as the transformation
would be a no-op in that case.  With more complicated view targetlists,
this omission would often lead to "attribute ... has the wrong type" errors
or even crashes, as reported by Mario De Frutos Dieguez.

Fix by adding code to rewriteTargetView to fix up the data structure
correctly.  The easiest way to update the exclRelTlist list is to rebuild
it from scratch looking at the new target relation, so factor the code
for that out of transformOnConflictClause to make it sharable.

In passing, avoid duplicate permissions checks against the EXCLUDED
pseudo-relation, and prevent useless view expansion of that relation's
dummy RTE.  The latter is only known to happen (after this patch) in cases
where the query would fail later due to not having any INSTEAD OF triggers
for the view.  But by exactly that token, it would create an unintended
and very poorly tested state of the query data structure, so it seems like
a good idea to prevent it from happening at all.

This has been broken since ON CONFLICT was introduced, so back-patch
to 9.5.

Dean Rasheed, based on an earlier patch by Amit Langote;
comment-kibitzing and back-patching by me

Discussion: https://postgr.es/m/CAFYwGJ0xfzy8jaK80hVN2eUWr6huce0RU8AgU04MGD00igqkTg@mail.gmail.com

Reset properly errno before calling write()

6cb3372 enforces errno to ENOSPC when less bytes than what is expected
have been written when it is unset, though it forgot to properly reset
errno before doing a system call to write(), causing errno to
potentially come from a previous system call.

Reported-by: Tom Lane
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/31797.1533326676@sss.pgh.pa.us

Add table relcache invalidation to index builds.

It's necessary to make sure that owning tables have a relcache
invalidation prior to advancing the command counter to make
newly-entered catalog tuples for the index visible.  inval.c must be
able to maintain the consistency of the local caches in the event of
transaction abort.  There is usually only a problem when CREATE INDEX
transactions abort, since there is a generic invalidation once we reach
index_update_stats().

This bug is of long standing.  Problems were made much more likely by
the addition of parallel CREATE INDEX (commit 9da0cc35284), but it is
strongly suspected that similar problems can be triggered without
involving plan_create_index_workers().  (plan_create_index_workers()
triggers a relcache build or rebuild, which previously only happened in
rare edge cases.)

Author: Peter Geoghegan
Reported-By: Luca Ferrari
Diagnosed-By: Andres Freund
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/CAKoxK+5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf=HEQ@mail.gmail.com
Backpatch: 9.3-

Add 'n' to list of possible values to pg_default_acl.defaclobjtype

This was missed in commit ab89e465cb20; backpatch to v10.

Author: Fabien Coelho <[email protected]>
Discussion: https://postgr.es/m/alpine.DEB.2.21.1807302243001.13230@lancre

Fix pg_replication_slot example output

The example output of pg_replication_slot is wrong.  Correct it and make
the output stable by explicitly listing columns to output.

Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/20180731.190909.42582169[email protected]

Remove no-longer-appropriate special case in psql's \conninfo code.

\conninfo prints the results of PQhost() and some other libpq functions.
It used to override the PQhost() result with the hostaddr parameter if
that'd been given, but that's unhelpful when multiple hosts were listed
in the connection string.  Furthermore, it seems unnecessary in the wake
of commit 1944cdc98, since PQhost does any useful substitution itself.
So let's just remove the extra code and print PQhost()'s result without
any editorialization.

Back-patch to v10, as 1944cdc98 (just) was.

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

Change libpq's internal uses of PQhost() to inspect host field directly.

Commit 1944cdc98 changed PQhost() to return the hostaddr value when that
is specified and host isn't.  This is a good idea in general, but
fe-auth.c and related files contain PQhost() calls for which it isn't.
Specifically, when we compare SSL certificates or other server identity
information to the host field, we do not want to use hostaddr instead;
that's not what's documented, that's not what happened pre-v10, and
it doesn't seem like a good idea.

Instead, we can just look at connhost[].host directly.  This does what
we want in v10 and up; in particular, if neither host nor hostaddr
were given, the host field will be replaced with the default host name.
That seems useful, and it's likely the reason that these places were
coded to call PQhost() originally (since pre-v10, the stored field was
not replaced with the default).

Back-patch to v10, as 1944cdc98 (just) was.

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

libpq: PQhost to return active connected host or hostaddr

Previously, PQhost didn't return the connected host details when the
connection type was CHT_HOST_ADDRESS (i.e., via hostaddr).  Instead, it
returned the complete host connection parameter (which could contain
multiple hosts) or the default host details, which was confusing and
arguably incorrect.

Change this to return the actually connected host or hostaddr
irrespective of the connection type.  When hostaddr but no host was
specified, hostaddr is now returned.  Never return the original host
connection parameter, and document that PQhost cannot be relied on
before the connection is established.

PQport is similarly changed to always return the active connection port
and never the original connection parameter.

Back-patch of commit 1944cdc98273dbb8439ad9b387ca2858531afcf0
into the v10 branch.

Author: Hari Babu <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Reviewed-by: Kyotaro HORIGUCHI <[email protected]>
Reviewed-by: David G. Johnston <[email protected]>

This reverts commit 85cd900fef99dab000bba7e2b6be541a03a48706.

I accidentally pushed a local change to the remote repo. So revert a revert.
Looks so stupid :-(

Use correct path for tablspaces while creating a basebackup

In XL, we embed the nodename in the tablespace subdir name to ensure that
non-conflicting paths are created when multiple coordinators/datanodes are
running on the same server. The code to handle tablespace mapping in basebackup
was missing this support.

Per report and patch by Wanglin.

Fix buffer usage stats for parallel nodes.

The buffer usage stats is accounted only for the execution phase of the
node.  For Gather and Gather Merge nodes, such stats are accumulated at
the time of shutdown of workers which is done after execution of node due
to which we missed to account them for such nodes.  Fix it by treating
nodes as running while we shut down them.

We can also miss accounting for a Limit node when Gather or Gather Merge
is beneath it, because it can finish the execution before shutting down
such nodes.  So we allow a Limit node to shut down the resources before it
completes the execution.

In the passing fix the gather node code to allow workers to shut down as
soon as we find that all the tuples from the workers have been retrieved.
The original code use to do that, but is accidently removed by commit
01edb5c7fc.

Reported-by: Adrien Nayrat
Author: Amit Kapila and Robert Haas
Reviewed-by: Robert Haas and Andres Freund
Backpatch-through: 9.6 where this code was introduced
Discussion: https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info

Match the buffer usage tracking for leader and worker backends.

In the leader backend, we don't track the buffer usage for ExecutorStart
phase whereas in worker backend we track it for ExecutorStart phase as
well.  This leads to different value for buffer usage stats for the
parallel and non-parallel query.  Change the code so that worker backend
also starts tracking buffer usage after ExecutorStart.

Author: Amit Kapila and Robert Haas
Reviewed-by: Robert Haas and Andres Freund
Backpatch-through: 9.6 where this code was introduced
Discussion:https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info

Revert "Correct select the GTM proxy for a new node being added"

This reverts commit edbe6703bf8d8749a807762135842b6a06309383.

Fix libpq's code for searching .pgpass; rationalize empty-list-item cases.

Before v10, we always searched ~/.pgpass using the host parameter,
and nothing else, to match to the "hostname" field of ~/.pgpass.
(However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by
"localhost".)  In v10, this got broken by commit 274bb2b38, repaired by
commit bdac9836d, and broken again by commit 7b02ba62e; in the code
actually shipped, we'd search with hostaddr if both that and host were
specified --- though oddly, *not* if only hostaddr were specified.
Since this is directly contrary to the documentation, and not
backwards-compatible, it's clearly a bug.

However, the change wasn't totally without justification, even though it
wasn't done quite right, because the pre-v10 behavior has arguably been
buggy since we added hostaddr.  If hostaddr is specified and host isn't,
the pre-v10 code will search ~/.pgpass for "localhost", and ship that
password off to a server that most likely isn't local at all.  That's
unhelpful at best, and could be a security breach at worst.

Therefore, rather than just revert to that old behavior, let's define
the behavior as "search with host if provided, else with hostaddr if
provided, else search for localhost".  (As before, a host name matching
DEFAULT_PGSOCKET_DIR is replaced by localhost.)  This matches the
behavior of the actual connection code, so that we don't pick up an
inappropriate password; and it allows useful searches to happen when
only hostaddr is given.

While we're messing around here, ensure that empty elements within a
host or hostaddr list select the same behavior as a totally-empty
field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b"
if DEFAULT_PGSOCKET_DIR is /tmp.  Things worked that way in some cases
already, but not consistently so, which contributed to the confusion
about what key ~/.pgpass would get searched with.

Update documentation accordingly, and also clarify some nearby text.

Back-patch to v10 where the host/hostaddr list functionality was
introduced.

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

Fix couple of compile time warnings

Move pgxc_clean to src/bin

Move pgxc_ctl to src/bin

pgxc_ctl is now widely used for cluster management and hence it makes every
sense to have it installed by default. In passing, also fix several
problems/kludges in the Makefile

pg_upgrade:  fix --check for live source server checks

Fix for commit 244142d32afd02e7408a2ef1f249b00393983822.

Backpatch-through: 9.3

Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.

Commits 742869946 et al turn out to be a couple bricks shy of a load.
We were dumping the stored values of GUC_LIST_QUOTE variables as they
appear in proconfig or setconfig catalog columns.  However, although that
quoting rule looks a lot like SQL-identifier double quotes, there are two
critical differences: empty strings ("") are legal, and depending on which
variable you're considering, values longer than NAMEDATALEN might be valid
too.  So the current technique fails altogether on empty-string list
entries (as reported by Steven Winfield in bug #15248) and it also risks
truncating file pathnames during dump/reload of GUC values that are lists
of pathnames.

To fix, split the stored value without any downcasing or truncation,
and then emit each element as a SQL string literal.

This is a tad annoying, because we now have three copies of the
comma-separated-string splitting logic in varlena.c as well as a fourth
one in dumputils.c.  (Not to mention the randomly-different-from-those
splitting logic in libpq...)  I looked at unifying these, but it would
be rather a mess unless we're willing to tweak the API definitions of
SplitIdentifierString, SplitDirectoriesString, or both.  That might be
worth doing in future; but it seems pretty unsafe for a back-patched
bug fix, so for now accept the duplication.

Back-patch to all supported branches, as the previous fix was.

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

Ensure that bad protocol ERROR message is sent to the frontend

In case of receiving bad protocol messages received by the GTM proxy, let
the client know about the error messages.

Correct select the GTM proxy for a new node being added

This fixes an oversight in array index lookup. We should have been using
0-based indexes but were instead using 1-based index.

Set ActiveSnapshot when logically replaying inserts

Input functions for the inserted tuples may require a snapshot, when
they are replayed by native logical replication.  An example is a domain
with a constraint using a SQL-language function, which prior to this
commit failed to apply on the subscriber side.

Reported-by: Mai Peng <[email protected]>
Co-authored-by: Minh-Quan TRAN <[email protected]>
Co-authored-by: Álvaro Herrera <[email protected]>
Discussion: https://postgr.es/m/4EB4BD78-BFC3-4D04-B8DA-D53DF7160354@webedia-group.com
Discussion: https://postgr.es/m/153211336163.1404.11721804383024050689@wrigleys.postgresql.org

Fix pg_dump's failure to dump REPLICA IDENTITY for constraint indexes.

pg_dump knew about printing ALTER TABLE ... REPLICA IDENTITY USING INDEX
for indexes declared as indexes, but it failed to print that for indexes
declared as unique or primary-key constraints.  Per report from Achilleas
Mantzios.

This has been broken since the feature was introduced, AFAICS.
Back-patch to 9.4.

Discussion: https://postgr.es/m/1e6cc5ad-b84a-7c07-8c08-a4d0c3cdc938@matrix.gatewaynet.com

Doc: fix oversimplified example for CREATE POLICY.

As written, this policy constrained only the post-image not the pre-image
of rows, meaning that users could delete other users' rows or take
ownership of such rows, contrary to what the docs claimed would happen.
We need two separate policies to achieve the documented effect.

While at it, try to explain what's happening a bit more fully.

Per report from Олег Самойлов.  Back-patch to 9.5 where this was added.
Thanks to Stephen Frost for off-list discussion.

Discussion: https://postgr.es/m/3298321532002010@sas1-2b3c3045b736.qloud-c.yandex.net

Ensure partition child tables inherit distribution properties correctly

While in restore mode, that we use to load schema when a new node is added to
the cluster, the partition child tables should correctly inherit the
distribution properties from the parent table. This support was lacking, thus
leading to incorrect handling of such tables.

Per report by Virendra Kumar.

Fix earthdistance test suite function name typo.

Affected test queries have been testing the wrong thing since their
introduction in commit 4c1383efd132e4f532213c8a8cc63a455f55e344.
Back-patch to 9.3 (all supported versions).

Document security implications of qualified names.

Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema
usage, and that advice suffices for using unqualified names securely.
Document, in typeconv-func primarily, the additional issues that arise
with qualified names.  Back-patch to 9.3 (all supported versions).

Reviewed by Jonathan S. Katz.

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

pgtest:  run clean, build, and check stages separately

This allows for cleaner error reporting.

Backpatch-through: 9.5