Improve node exclusion and node rejoining logic for calculation for global
xmin.

When a node rejoins the cluster, after disconnection or restart, the logic now
accounts for the fact that the node might be running with an older xmin. GTM
sends back appropriate error codes and recent state information so that the
node can make a decision to join the cluster or fail.

Also increase the threshold for delay in reporting to 10mins to avoid false
positives.

Improve node registration and xmin reporting such that false log messages are
avoided at the GTM.

Also add some more debug messages to the GTM

Do not log unnecessary node registration failures by differentiating between a
node and session registration

Some misc fixes and documentation updates for pgxc_ctl

Sprinkle SQueue and portal management code with DEBUG messages

Test sql and output changes for hstore

Add order by clause for consistent test results from
json_agg() function

Adjust log_line_prefix to log much more information about connections.

'R' - now reports information about remote end (type/name/pid) where type can
be 'C' for coordinator, 'D' for datanode, 'A' for application and 'U' for rest

'G' - now reports information about the originating coordinator (name/pid)

'S' - reports the global session identifier.

Let many GUC parameters be user-settable, compatible with PG.

They were made SUSET to support multi-tenant environment, but no longer
applicable to the current use case of XL.

Some improvements to debug/error logging.

We now log name of the remote node and remote PID if an error is received on a
connection. Some more debugging messages added to the pooler code.

Track PID of the remote backend processes serving a particular connection.

This information is usally readily available in PGConn, but since we only pass
around socket descriptors between pooler and the coordinator (or datanode
backends), we pass this information back to the backends. This is at least very
useful for debugging purposes.

(This API definitely deserves some refactoring. In particular, I would like to
keep a copy of some other members of the PGConn structure in the
PGXCNodeHandle, but for now backend PID is what we care for).

Add support for overrding default log levels for specfic messages or all
messages in a file or a module.

We now support a new --enable-genmsgids configure option. When compiled with
this, superusers can run pg_msgmodule_set(moduleid, fileid, msgid, newlevel)
command to override the log level specified in the source code.

There are many TODOs and limitations of this approach. We could only, for
example, increase logging level of messages i.e. turn DEBUG2 to DEBUG1 or DEBUG
to LOG. But we can't change ERROR to PANIC or supress a log message. Also, we
are using a very sparse representation of the message log levels. This
increases memory requirements significantly, though should speed up lookups and
keep the code simple.

When configured with --enable-genmsgids, a file named MSGMODULES is created at
the top of the build tree and the module-ids are later picked from that file
while compiling individual files. We would also preprocess each file before
compilation and save all elog() calls, along with the file_name, line_number,
messgae, module_id, file_id, msg_id in MSGIDS file. This file can then be used
to lookup the messages so that correct information is passed. This clearly
needs a lot more polishing and work.

When configued without --enable-genmsgids, we don't expect this facility to add
overhead because all codes gets #ifdef-ed out

Standardize "subdir = <name>" in the Makefile(s)

Add a mechanism to start with an empty pgxc_ctl configuration file and build
the cluster one at a time.

A new option "prepare config empty" is now supported which sets up an almost
empty conf file and all components, including GTM, can be added one at a time

Handle MergeAppend node correctly while determing param types.

Report by Krzysztof Nienartowicz, patch by me.

If we don't find GTM control file on startup, look for the temporary control
file and use that.

While updating the control file, GTM first writes updated content to a temp
file, then deletes the old file and renames the temp to the control file. But
in a rare situation, its possible that GTM may exit before renaming the temp
file. In such cases, we should use the temp file after renaming it to the
orignal file.

More improvements in this area are necessary.

P.S. This commit gets distinction to be the first commit, pushed from 41000
feet in the air ;-)

Test output and sql changes

Run rangefuncs separately in parallel_schedule,
as it has table names common with group.

Add expected output previously removed.

Add back as it is needed on some systems.

Test output and sql changes

Change comments on FQS of query as per behavior #59
Separate out an issue #67 from xc_copy

Fix collate regression case by removing an ORDER BY (added in XL) which seems
to produce different results on different platforms.

Expected output adjusted accordingly

Change expected output for 'transactions' test case which seems to be working
fine after recent bug fixes.

Exponetially increase the sleep before retrying commit on the GTM.

When a transaction waits for another transaction to complete, we enforce the
same ordering on the same GTM by making the former transaction wait on the
latter. We do this by a simple retry logic. While the latter transaction should
ideally finish soon because it has already finished on the datanode, the retry
loop now waits exponentially, starting at 1000usec but limited by 1s.

Patch by Mason Sharp

Do not throw a FATAL error when SharedQ producer times out while waiting for
one or more consumers to finish.

We have seen bunch of cases where a consumer may never bind to the SharedQ and
rightfully so. For example, in a join between 3 tables which requires
redistribution of tuples, a consumer may not at all bind to the SharedQ because
it the top level outer side did not produce any tuples to join against the
redistributed inner node.

This patch avoids the unnecessary FATAL errors, but what we still do not do
nicely is to avoid the 10s timeout (as currently set for producer). So while
queries, as included in the test case, will finally return success, it will
unnecessarily add a 10s delay in the response time. This is a TODO.

Remove a WARNING about coordinator provided snapshot not available.

There are a few expected cases, such as catalog scans, where coordinator
supplied snapshot may not be available. So remove this mis-leading warning.

Fix a bug where queries would incorrectly get executed on the coordinator.

Report by Krzysztof Nienartowicz, patch by me.

Do not hold the XidGenLock while obtaining an XID from the GTM

This was an oversight when on-demand GXID work was committed. Mason reported
that this patch significantly improves performance on his tests and I can
also confirm that with my own tests.

Report and patch by Mason Sharp, with some changes from me.

Test output and sql changes

Fix 2 tests. Partial fix for xc_copy diffs.

Avoid redefinition of a signal handler signature

Do not override the sequence_range setting in COPY

The default value of this parameter has now been hiked to 1000. So there is no
good reason to override this in COPY, if the user has explicitly set it back to
1. Honor user defined value in all cases.

We can possibly flag a warning if sequences are being incremened too fast and
the current value of sequence_range is set too low. But no compelling need to
do that just now.

Test output and sql changes

Accept outputs, with some known bugs added.

Test sql and output changes

Comment out known issues and add them to kown bugs.

Test output changes

Fix 2 tests.

Change expected output - can't do FQS for a GROUP BY query on a roundrobin
table

Fix a bug where a query was getting incorrectly FQSed when the GROUP BY clause
contains only non-distribution keys.

Also rerun all the xc_groupby tests with enable_fast_query_shipping ON so that
similar issues can be caught more easily

Fix a protocol message to register the GTM proxy

Fix compiler warnings in stormstats, some of which may also cause failures on
other platforms.

Add missing DISTRIBUTE RANDOMLY to the specs in the documentation

Change expected output for select_views test case.

Change some part of expected output file for test case rowsecurity, related to
XL plan changes.

Change expected output for prepared_xacts test case to accept newer changes
from PG

Test output changes

Accept some XL outputs for tests.

Avoid using EXPLAIN VERBOSE when temp tables are involved in a test case.

In XL, the temporary schema may change in different regression runs. Hence we
must not print the schema in expected output. Change the sql as well as
expected output file for the 'join' test case.

Change expected output for test case xc_alter_table which matches current
behaviour

Change expected output for test case xc_FQS_join now that queries are properly
FQSed to the remote (via 1083af3fa)

Change expected output for test case xc_having now that we support
enable_fast_query_shipping GUC

Change expected output for xc_groupby test case now that
enable_fast_query_shipping GUC is supported and the entire test case runs with
the GUC turned off

Fix a bug where we will pick up random nodes for individual replicated tables,
thus reducing the chances of query getting fully shipped to the remote node.

We now remember all nodes that can satify a READ request for a replicated table
and then finally choose a node randomly if no preferred datanode is specified.
This will avoid non-deterministic selection of FQS query plans as well as allow
us to send some more queries to the remote node.

Add enable_fast_query_shipping GUC to control whether to attempt Fast Query
Shipping to the remote node or not

Its primary use is for debugging purposes

Test output and sql changes

Fix rowtypes with nodes off in query plan
Simplify diffs seen in ome xc_* tests.

Test output and sql changes

Fixes 6 tests.

Mainly accepts known limitations and uses 'nodes off'
for query plan.

Further improvements to release notes

The XLOG dirs in the pgxc_ctl conf file are optional

Add a changes missed in the previous commit.

Add support to specify separate XLOG dirs for datanode masters and datanode
slaves in pgxc_ctl.conf file as well as corresponding "add" commands.

Recent releases of Postgres now allow users to specify a separate XLOG dir and
initdb time and we extend the same facility to pgxc_ctl.

Change expected output for updatable_views test case by not printing node
information

This makes test output more deterministic. The test case still does not pass
because of an additional diff that requires further analysis.

Set sequence_range to 1 while initialising nodes for "make check" so that
deterministic output is obtained.

This avoids explicit setting of the GUC in every test case that uses serials or
sequences. For those running "make installcheck" they must set it up correctly
in their postgresql.conf files.

We could revert some of the changes done to the test cases (by adding
sequence_range = 1), but this patch does not do that

Change expected output for create_view test case.

We expect to see a Remote Subquery Scan node in the explain plan.

Change expected output for timestamp/timestamptz tests

Looks like they were mistakenly changed while a bug existed. Now that the bug
is fixed, they are giving the correct output, matching PG's results.

Recheck health of a node before changing its status.

send/recv() errors just give us a hint about something going wrong with a node.
But a mere send/recv failure does not mean that the node is down or
unreachable. So before changing the health status, ping the node once and
confirm its health status.

Assign coordinator local timestamp when transaction timestamp is requested
before or without assigning XID to the transaction.

GTM supplied timestamp is available only when a transaction has started on the
GTM. But for read-only transactions or transactions which are yet to do any
database write activity, we avoid going to GTM for performance reason. For such
cases, use coordinator local timestamp and continue to use the same for rest of
the transaction.

First draft of release notes.

Speedup 2PC by skipping two phase state files in normal path

2PC state info is written only to WAL at PREPARE, then read back from WAL at
COMMIT PREPARED/ABORT PREPARED. Prepared transactions that live past one bufmgr
checkpoint cycle will be written to disk in the same form as previously. Crash
recovery path is not altered. Measured performance gains of 50-100% for short
2PC transactions by completely avoiding writing files and fsyncing. Other
optimizations still available, further patches in related areas expected.

Stas Kelvich and heavily edited by Simon Riggs

Based upon earlier ideas and patches by Michael Paquier and Heikki Linnakangas,
a concrete example of how Postgres-XC has fed back ideas into PostgreSQL.

Reviewed by Michael Paquier, Jeff Janes and Andres Freund
Performance testing by Jesper Pedersen

Refactor to create generic WAL page read callback

Previously we didn’t have a generic WAL page read callback function,
surprisingly. Logical decoding has logical_read_local_xlog_page(), which was
actually generic, so move that to xlogfunc.c and rename to
read_local_xlog_page().
Maintain logical_read_local_xlog_page() so existing callers still work.

As requested by Michael Paquier, Alvaro Herrera and Andres Freund

Merge upto commit 'cdd4ed5449bf317cc71b45a8deee0173822e7592' which corresponds
to 9.5.0 release of PostgreSQL

Test output and sql changes.

Fixes 9 tests.

Reasons:

set sequence_range as 1 for sequences and datatype
to work fine,
run advisory_lock independently in parallel
schedule, as XL uses them internally too,
no support in XL to refresh materialized views
concurrently.

We don't yet support persistent connections between datanodes

Fix an oversight in the previous commit

Fix various potential buffer overflows which got exposed after we recently
increased GIDSIZE

Per report by Tobias Oberstein

Use XID passed down by the remote datanode, if its available, when
GetCurrentTransactionIdIfAny() is called.

The regular GetCurrentTransactionId() does the same, without actually storing
the XID in the transaction state. We don't store the XID when the connection is
from a datanode, to ensure that a duplicate XID is not stored. There are other
technique employed to ensure multiple backends can participate in the same
global transaction.

This bug was causing wrong results when a query needs datanode-datanode
connections and updates are made previously in the same transaction, via a
different connection

Per report by Arun Shaji

Accept XL test output.

Fixes 17 tests.

Reasons:

timestamp Issue, some ERROR string differences,
remote subquery plan differences.

No support in XL for: TRIGGERS, correlated UPDATE,
SAVEPOINT, WHERE CURRENT OF, internal subtransactions,
complicated SELECT queries in plpgsql functions,
distribution column in child table to refer to non
distribution column in referenced table,
ORDER BY in subqueries, FOREIGN DATA WRAPPER, SERVER,
USER MAPPING

WAL log only the actual GID instead of the entire GIDSIZE data

While GIDSIZE is set to quite high (actually, in XL its even more than 200
bytes currently defined in PG), in practice, the GID will be much smaller in
length. So instead of WAL logging the entire GIDSIZE data, we only log the
actual GID string. This shows considerable improvement for XL

Remove an unnecessary newline which may cause conflicts with upstream patches

Remove an unintentional stderr message mistakenly committed
in 8a519fbc16bedd

Support yet another syntax for specifying distribution strategy for
a table

DISTSTYLE KEY DISTKEY (col) maps to DISTRIBUTE BY HASH (col)
DISTSTYLE EVEN maps to DISTRIBUTE BY ROUNDROBIN
DISTSTYLE ALL maps to DISTRIBUTE BY REPLICATION

Support additional synax for choosing table distribution strategy

DISTRIBUTED BY (col) maps to DISTRIBUTE BY HASH (col)
DISTRIBUTED RANDOMLY maps to DISTRIBUTE BY ROUNDROBIN

Check if target directory is empty (if it already exists) on the remote node.

We were wrongly doing this check on the local node, which was clearly wrong.

Introduce a healthmap for tracking health status of all other nodes in the
cluster.

Each node now maintains a healthmap in shared memory to keep track of
availability of all other nodes in the cluster. Whenever a send() or a
receive() call on a socket fails, we try to ping the node once and if that
fails, we mark the node as UNHEALTHY. On the other hand, if later a new
connection is established successfully to a node, we mark the node as HEALTHY.
We also periodically try to ping UNHEALTHY nodes to see if they have come back
to life and update the healthmap accordingly.

The only consumer of a healthmap right now is SELECT queries on replicated
tables. When a table is replicated to more than one node, we now consult the
healthmap and discards nodes that are known to be UNHEALTHY. If all nodes are
found to be UNHEALTHY, one attempt is made to see if any of them have come back
online.

Fix "make check" so that it now sets up a 2-coordinator, 2-datanode XL cluster
and runs a parallel schedule

There were different problems with the way various components were being set
up, including specifying a separate directory to create domain sockets. The
names used for datanodes were also different than what the regression expected
output has. This patch fixes that too

Test output, sql changes

exclude query plan on replicated tables - join
exclude complex queries with 'union all' - equivclass
set sequence_range for nextval() to work fine - xl_functions
accept some FQS format changes in output

Select a node randomly from a list of available nodes for reading from
replicated tables

This fixes a bug in FQS logic where it would always pick up the same node for
reading

Send out a relcache inval for the relation when its distribution key or
strategy changes.

Without this backends may not reload their relcache entries and thus keep
looking at the old and stale distribution information

Do not use FQS for queries with FOR UPDATE/SHARE clause

Send XID assigned on a datanode back to the coordinator.

We'd missed out a case where XIDs are assigned on a datanode, but the same is
not sent back to the coordinator. We now also avoid running a 2PC for
transactions which do not have XID assigned to them since such transactions
must not have made any database changes

Test, sql changes for insert_conflict

Accept ERROR for unique index on non-distribution column.
Remove tableoid call, with bug reference.

For FQSed query, run EXPLAIN on the remote node and print the result

We recently added fast-query-shipping facility to Postgres-XL. But it wouldn't
print the query plan used on the datanodes, which makes it extrememly difficult
to debug bad query plan with EXPLAIN. We now send an EXPLAIN query to one of
the datanodes and print the result. This assumes that all datanodes would plan
queries similarly, assuming a good data distribution.

We also modified the EXPLAIN output for FQSed queries to match is as closely as
possible with the Remote Subplan queries.

Fix misc issues with two-phase commit protocol and cleaning up of outstanding
transactions

When a two-phase commit protocol is interrupted mid-way, for example because of
a server crash, it can leave behind unresolved prepared transactions which must
be resolved when the node comes back. Postgres-XL provides a pgxc_clean utility
to lookup list of prepared transactions and resolve them based on status of
such a transaction on every node. But there were many issues with the utility
because of which it would either fail to resolve all transactions, or worse
resolve it in a wrong manner. This commit fixes all such issues discovered
during some simple crash recovery testing.

One of the problem with the current approach was that the utility would not
know which all nodes were involved in a transaction. So if it sees a
transaction as prepared on a subset of nodes, but does not exist on other
subset, it would not know if originally it was executed on nodes other than
where its prepared, but other nodes failed before they could prepare the
transaction. If it was indeed executed on other nodes, such transaction must be
aborted. Whereas if it was only executed on the set of nodes where its
currently prepared, then it can safely be committed.

We now store the information about nodes partcipating in a 2PC directly in the
GID. This of course has a downside of increasing the GIDSIZE which implies for
shared memory requirement. But with today's server sizes, it should not be a
very big concern. Sure, we could also look at possibility of storing this
information externally, such as on the GTM. But the fix seems good enough for
now.

Test changes for insert_conflict

Accept output changes - we now avoid an additional local connection.

Fix some protocol issues between GTM and GTM-standby.

Make idle backends exit if the postmaster dies.

Letting backends continue to run if the postmaster has exited prevents
PostgreSQL from being restarted, which in many environments is
catastrophic.  Worse, if some other backend crashes, we no longer have
any protection against shared memory corruption.  So, arrange for them
to exit instead.  We don't want to expend many cycles on this, but
including postmaster death in the set of things that we wait for when
a backend is idle seems cheap enough.

Rajeev Rastogi and Robert Haas

Test changes

Changes related to expected output for XL tests, concerning
insensitive cursor, recursive queries, grouping sets, literal
constants autocast.

End global transaction on the GTM before releasing locks.

Since other backends could be waiting for locks to be released and they must
see end of the transaction, not just locally but also on the GTM (say because
it takes a new snapshot from the GTM, especially for catalog scans). There are
some concerns about doing it the way its done in this patch because we now
exchange messages with the GTM while holding interrupts. But we don't know if
thats really a problem

Bump default value for sequence_range to 1000.

This shows good improvement for workloads which repeatedly asks for sequence
values. We already override the sequence_range value to 1000 for COPY and it
makes a lot of sense to do the same for INSERTs

Correctly handle RESPONSE_WAITXIDS response from a datanode

Ensure commit ordering at the GTM when a transaction's update/delete operation
is based on some other transaction's commit

We had handled one part of this problem by recording transactions on which we
wait before proceeding with update/delete. But there is another case where an
updating transaction T1 may commit on the datanode, but before coordinator can
commit the transaction on the GTM, another transaction T2 updates the record
(seeing that the updating transaction is already committed) and also commits on
the GTM. Now if a third transaction T3 takes a snapshot, it will see T1 as
running and T2 as committed. Such a snapshot can then see both old and new
versions of the updated tuple. So we must enforce commit ordering T1->T2 on the
GTM since T2 based its actions on T1 being committed

Stamp 9.5.0.

Docs: provide a concrete discussion and example for RLS race conditions.

Commit 43cd468cf01007f3 added some wording to create_policy.sgml purporting
to warn users against a race condition of the sort that had been noted some
time ago by Peter Geoghegan.  However, that warning was far too vague to be
useful (or at least, I completely failed to grasp what it was on about).
Since the problem case occurs with a security design pattern that lots of
people are likely to try to use, we need to be as clear as possible about
it.  Provide a concrete example in the main-line docs in place of the
original warning.

Adjust behavior of row_security GUC to match the docs.

Some time back we agreed that row_security=off should not be a way to
bypass RLS entirely, but only a way to get an error if it was being
applied.  However, the code failed to act that way for table owners.
Per discussion, this is a must-fix bug for 9.5.0.

Adjust the logic in rls.c to behave as expected; also, modify the
error message to be more consistent with the new interpretation.
The regression tests need minor corrections as well.  Also update
the comments about row_security in ddl.sgml to be correct.  (The
official description of the GUC in config.sgml is already correct.)

I failed to resist the temptation to do some other very minor
cleanup as well, such as getting rid of a duplicate extern declaration.

Fix typo in comment.

Masahiko Sawada

Translation updates

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 3b0ccc27cf917446ea0a6c680b70534cfcaba81e

Fix regrole and regnamespace output functions to do quoting, too.

We discussed this but somehow failed to implement it...

Fix regrole and regnamespace types to honor quoting like other reg* types.

Aside from any consistency arguments, this is logically necessary because
the I/O functions for these types also handle numeric OID values.  Without
a quoting rule it is impossible to distinguish numeric OIDs from role or
namespace names that happen to contain only digits.

Also change the to_regrole and to_regnamespace functions to dequote their
arguments.  While not logically essential, this seems like a good idea
since the other to_reg* functions do it.  Anyone who really wants raw
lookup of an uninterpreted name can fall back on the time-honored solution
of (SELECT oid FROM pg_namespace WHERE nspname = whatever).

Report and patch by Jim Nasby, reviewed by Michael Paquier