Remove unnecessary ORDER BY clauses from plpgsql tests

Some of the tests produce stable ordering even without the explicit
ORDER BY clauses, due to only using generate_series() and not any
distributed tables. So get rid of the unnecessary ORDER BY clauses.

Fix expected output for plpgsql test suite

Commit 7d55b3a318 accepted incorrect expected output for a number
of tests in this suite. The issue might have been initially masked
by existence of another .out file for this test.

We seem to be producing the correct output, so just use expected
output from upstream. Moreover, the table (INT4_TBL) is defined as
replicated, so we don't need the explicit ORDER BY clauses as the
ordering is stable anyway. So remove them, to make the the tests
a bit closer to upstream.

Accept correct output/plan in subselect test suite

The value 200 is in fact incorrect, and commit 159912518 accepted it
by mistake. The query should have produced 100 (which it now does).

The plan is correct, and matches the plan produced on PostgreSQL 10
(although with Remote Subquery Scan on top).

Update cmin values in combocid based on XL 9.5

As mentioned in 3a64cfdde3, some of the output differences (compared
to PostgreSQL 10) may be caused by XL advancing cmin more often, for
example due to splitting a single command into multiple steps.

So tweak the expected output using output from Postgres-XL 9.5r1.6.

Stabilize combocid test by replicating the table

Commit 1d14325822 randomized the choice of a starting node with
ROUNDROBIN distribution, so that the data in combocid tests are not
all placed on the first node but distributed randomly (despite using
single-row INSERTS as before).

So to stabilize the test, make the table replicated. The table only
has a single column and the test updates is, so we can't use any
other stable distribution (e.g. BY HASH).

The expected results were obtained by running the combocid.sql on
PostgreSQL 10, so there might be some cmin differences.

Accept warnings about inheriting distribution from parent

Commit e26a0e07d8 started ignoring distributions defined on partitions,
but omitted this place in 'rules' when accepting the warnings.

Add explicit VACUUM to stabilize plans in inherit tests

On stock PostgreSQL, CREATE INDEX also updates statistics in pg_class
(relpages and reltuples). But Postgres-XL does not do that, which may
result in plan differences when the test relies on this behavior.

This is the same issue as in cfb055553687c257dd1d1ed123356c892f48a804,
but affecting inherit regression tests. So fix it in the same way, by
doing an explicit vacuum on the tables.

Accept plan changes in 'limit' test suite

The accepted plan changes seem correct, as the only difference with
respect to upstream plans is Limit distribution. The commit diff is
a bit more complicated, because the expected plan did not reflect
the switch from Result to ProjectSet.

Accept plan change in 'inherit' test suite

The plan change is expected, as it simply expands

    -> Limit

to
    -> Limit
        -> Remote Subquery Scan
            -> Limit

It wasn't accepted before probably because it was hidden by other
failures in the test suite.

Disable FQS for cursors defined with SCROLL

When checking if a query is eligible for FQS (fast-query shipping),
disable the optimization for queries in SCROLL cursors, as FQS does
not support backward scans.

Discussion: <e66932f3-3c35-cab0-af7e-60e8dfa423ba@2ndquadrant.com>

Fix the pg_basebackup call when adding standby nodes

When adding standby nodes using pgxc_ctl, it's calling pg_basebackup
internally. But the "-x" option was removed in PostgreSQL 10, so the
call is failing.

A straightforward fix would be to use "-X fetch" which does exactly
what "-x" used to do. But I've decided to use "-X stream" instead,
as that does not rely on wal_keep_segments.

Reported by Tank.zhang"<6220104@qq.com>, along with "-X fetch" fix.

Fix minor regression failure in updatable_views

The ATTACH PARTITION command was failing due to mismatching column
order. That in turn caused failure in sanity_check, as the table
was not dropped when dropping the parent.

Fix expected output in select_view test

The expected output did not match, likely due to some confusion when
merging upstream changes (where the query does not include the ORDER
BY clause).

The updated output matches exactly to what is produced by upstream
after adding the ORDER BY clause.

Improve shared queue synchronization further

Our efforts to improve shared queue synchronization continues. We now have a
per queue producer lwlock that must be held for synchronization between
consumers and the producer. Consumers must hold this lock before setting the
producer latch to ensure the producer does not miss out any signals and does
not go into unnecessary waits.

We still can't get rid of all the timeouts, especially we see that sometimes a
producer finishes and tries to unbind from the queue, even before a consumer
gets chance to connect to the queue. We left the 10s wait to allow consumers to
connect. There is still net improvement because when the consumer is not going
to connect, it tells the producer and we avoid the 10s timeout, like we used to
see earlier.

Enable Hot Standby on the replicas

We had an issue with tracking knownXids on the standby and it was overflowing
the allocated array in the shared memory. It turned out that the primary reason
for this is that the GTM leaves behind a hole in XID allocation when it's
restarted. The standby oblivious to this, was complaining about array overflow
and thus die.

We now fix this by allocating array which can hold CONTROL_INTERVAL worth
additional XIDs. This would mostly be a waste because the XIDs are never
allocated. But this seems like a quick fix to further test the Hot standby. The
good thing is that we might just waste memory, but not have any impact on the
performance because of larger array since we only loop for numKnownXids which
will be more accurate.

With this change, also fix the defaults for datanode and coordinator standbys
and make them Hot Standbys. The wal_level is changed too.

Handle Aggref->aggargtypes in out/readfuncs.c

When communicating with other nodes, we send names of objects instead
of OIDs as those are assigned on each node independently. We failed to
do this for Aggref->aggargtypes, which worked fine for built-in data
types (those have the same OID on all nodes), but resulted in failures
for custom data types (like for example FIXEDDECIMAL).

   ERROR:  cache lookup failed for type 16731

This fixes it by implementing READ/WRITE_TYPID_LIST_FIELD, similarly
to what we had for RELID.

Note: Turns out the WRITE_RELID_LIST_FIELD was broken, but apparently
we never call it in XL as it's only used for arbiterIndexes field. So
fix that too, in case we enable the feature in the future.

Ensure that we don't read rule definition with portable input on

Rules are converted in their string representation and stored in the catalog.
While building relation descriptor, this information is read back and converted
into a Node representation. Since relation descriptors could be built when we
are reading plan information sent by the remote server in a stringified
representation, trying to read the rules with portable input on may lead to
unpleasant behaviour. So we must first reset portable input and restore it back
after reading the rules. The same applies to RLS policies (even though we don't
have a test showing the impact, but it looks like a sane thing to fix anyways)

Fix trivial failure in rangefuncs test suite

Commit f7d1d581c950191a465b8483173f2ad69ae8fffe converted a couple of
sequences to persistent (instead of temporary), but failed to update
the expected output.

Fix incorrect planning of grouping sets

Commit 04f96689945462a4212047f03eb3281fb56bcf2f incorrectly allowed
distributed grouping paths for grouping sets, causing failures in
'groupingsets' regression test suite. So fix that by making sure
try_distributed_aggregation=false for plans with grouping sets.

Ensure that database objects are created consistently.

We now create views/materialised views on all nodes, unless they are temporary
objects in which case they are created only on the local coordinator and the
datanodes. Similarly, temporary sequences are created on the local coordinator
and the datanodes.

This solves many outstanding problems in the regression results where remote
nodes used to fail because of non-existent type for a view or similar such
issues. A few other test cases now started to work correctly and produce output
matching upstream PG. So the expected output for those test cases has been
appropriated fixed.

Couple of sequences in the rangefuncs test case have been converted into
permanent sequences because the subsequent SQL functions refer to them and
hence fail if they do not exist on the remote coordinators.

The problem with special RULE converting a regular table into a view goes away
with the fix since DROP VIEW commands are now propgataed to the datanodes too.

Further refactoring of utility.c code

Furthre more simplification and consolidation of the code.

Rearrange switch cases so that they are grouped together when possible

Refactor changes in the utility.c

Stamp Postgres-XL 10alpha2

Assorted fixes to documentation compilation

Accept differences in tsm_system_time contrib module

Trivial plan changes and missing bits (likely due to incorrect merge
or something like that).

Accept plan changes in tsm_system_rows contrib module

Trivial changes due to distributing the queries.

Stabilize ordering in tablefunc contrib module

Add explicit ORDER BY clause to stabilize ordering of test results.

Remove FDW objects from tests in pgstattuple contrib module

Postgres-XL does not support FWD object, so the tests were failing
with "does not exist" errors, instead of testing that visibility on
FDW objects is not supported. So just remove the few test queries.

Remove FDW objects from tests in pg_visibility contrib module

Postgres-XL does not support FWD object, so the tests were failing
with "does not exist" errors, instead of testing that visibility on
FDW objects is not supported. So just remove the few test queries.

Stabilize ordering of results in pg_trgm contrib module

Add explicit ORDER BY clause to stabilize ordering of results for
a few tests. Accept a simple plan change, distributing a LIMIT query.

Accept plan changes in btree_gist contrib module

The changes are fairly simple and generally expected due to distributing
upstream queries, so adding either Remote Fast Query Execution or Remote
Subquery Scan nodes.

An explicit ORDER BY was added to a few queries to stabilize the output.

Accept plan change in btree_gin contrib module

The upstream plan changes due to distributing to multiple nodes.

Accept plan changes in bloom contrib module

The changes are fairly simple and generally expected due to distributing
upstream queries, so adding either Remote Fast Query Execution or Remote
Subquery Scan nodes.

Disable logical decoding as unsupported

Commit 665c224a6b2afa disabled CREATE PUBLICATION/SUBSCRIPTION, but
it was still possible to create a logical replication slot and call
pg_logical_slot_get_changes() on it.

That would however crash and burn as ReorderBufferCommit() relies on
subtransactions, and BeginInternalSubTransaction() is not expected
to fail, leading to segfaults in the PG_CATCH block.

Simply disallowing creating logical slots (and whatever else relies
on CheckLogicalDecodingRequirements) seems like the best fix.

Accept regression diffs in stats_ext test case

The actual result matches with the upstream result. The diffs must have been
caused by incorrect merge. So accept those fully.

Fetch the target remote nodes to run CREATE STATISTICS command

Some database objects are created only on a subset of nodes. For example, views
are created only on the coordinators. Similarly, temp tables are created on the
local coordinator and all datanodes. So we must consult the relation kind
before executing the CREATE STATISTICS command on the remote nodes. Otherwise
we might try to execute it on a node where the underlying object is missing,
resulting in errors.

Patch by senhu ([email protected]) which was later reworked by me.

Accept regression diffs in update test case

The first diff was in fact a mistake and the actual output matched with the
upstream output. It must have been missed during the merge process. The other
diff was simply an error because XL doesn't allow updating distribution key
column.

Fix plpgsql regression test

There were two broad categories of problems.

1. Errors due to lack of savepoint support
2. Errors and side effects due to lack of trigger support.

For 1, we reorganised the test case so that they can be run without savepoint.
For 2, we mostly accepted the regression changes. Apart from usual errors while
creating/dropping triggers, there were differences in query results because
of changes to preceding update/insert/delete statements. The behaviour of those
statements change because of lack of triggers.

Fix alter_table test case

Because of XL's strict requirement on column ordering and positioning, change
the test case to avoid DROP COLUMN commands. This kinda makes the test case
useless because the sole purpose of the test was to test if things stand up
well when there is a mismatch in column numbering. Given the current
restriction, there is no other option to make these changes.

Do not add any distribution to a dummy append node

A dummy append node with no subpaths doesn't need any adjustment for
distribution. This allows us to actually correct handle UPDATE/DELETE in some
cases which were failing earlier.

Much restructing of rowsecurity test case

- Some problems related to inherited tables fixed by ensuring column ordering.
- ORDER BY clauses added at some other places to ensure consistent row ordering.
- Changes related to TABLESAMPLE accepted as XL returns more rows than PG
- SAVEPOINTs removed and replaced by transaction blocks as XL does not support
  subtransaction
- NOTICEs are not displayed in XL
- Append is pushed down to the remote node now that we impose stricter
  restrictions on inheritance

Make float8_tbl replicated to stabilize float8 test

As the table has just a single float8 column, XL automatically picks
ROUNDROBIN distribution. Commit 1d14325822 randomized selection of the
initial node, which with single-row inserts (used by the float8 tests)
effectively means random distribution, while before that all the rows
would be routed to the first node.

Some of the tests in float8 test suite seem to be sensitive to this, in
particular this overflow test:

    SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f ORDER BY f1;
    ERROR:  value out of range: overflow

One of the rows (containing 1.2345678901234e-200) triggers an underflow,
so when the database hits it first, it will report this error instead:

    ERROR:  value out of range: underflow

The probability of hitting this is however fairly low (less than 10%),
as the executor has to touch the underflowing value first.

Fix prepared_xacts test case

Remove a SAVEPOINT statement, which otherwise fails. Once that is removed, a
few other test cases work fine and the associated expected output changes are
accepted.

Accept regression diffs in select_implicit test case

It was a simple case of change in row ordering because the test case is
requesting order by column 'a', but the expected output had order by column 'c'

Accept regression diff in tablesample test case

It's just an addition of a Remote Subquery Scan node on top of the regular
plan.

Do not try to set invalid value for guc

We don't support subtransactions and hence can't handle exception thrown by
trying to set invalid value. We'd already removed the exception, but the
transaction was being left in an aborted state. So fix this.

The test case still fails for some other reason which should be investigated
separately.

Accept regression diffs in select_views test case

These changes were lost when we removed alternate expected output files for the
test case. So these are not new differences and the same ordering is exhibited
in XL9.5 as well.

NOTICEs are not shown by XL so accept those differences.

Make adjustment to foreign_key test case

Accept some diffs which look sane and in-line with the upstream errors. Also
comment out a few tests which explictly test subtransactions, something we
don't currently support.

Accept errors in hash_index test case

We don't support BACKWARD scan of RemoteSubplan and neither support WHERE
CURRENT OF. So accept the resulting errors.

Accept errors in tidscan regression test

We don't support BACKWARD scan of RemoteSubplan and neither support WHERE
CURRENT OF. So accept errors arising out of these limitations. These test case
changes are new in XL10 and hence we did not see these failures in the earlier
releases of XL.

Make adjustments to combocid test so that it passes

SAVEPOINTs were used, which we don't support. So commented those out (along
with ROLLBACK calls). That does have an impact on the test case though because
at least in one place we were checking if the cmin goes back to 0 after rolling
back to a savepoint. But there is not much we can do about that until we add
SAVEPOINT support. Other changes include accepting diffs because of ctid
changes as rows come from different nodes and hence ctids are
duplicated/changed.

Accept regressions diffs in copy2 test case

We do not support trigger and hence the regression differences.

Accept regression differences in polymorphism test case

As with other test cases, accept the lack of NOTICEs in the test case. This
issue needs to be investigated, but surely this is not the only test case
that's suffering from this behavioural change. So accept for now and change
later once (and when) we fix the NOTICE problem.

Fix identity test case

Accept some differences as the identity column is also used distribution
column and hence updates are disallowed in XL. So accept those differences (we
should later add XL-specific test cases by having identity in non-distribution
column). Also add ORDER BY in some select queries to ensure consistent ordering
of the result

Accept regression differences in largeobject test case

Since large objects are not supported by XL, these were mostly cosmetic
differences without any possible bug.

Handle rescan of RemoteQuery node correctly

We never had this support and we never felt the need because the use of FQS was
limited for utility statements and simple queries which can be completed
pushed down to the remote node. But in PG 10, we're seeing errors while using
cursors for queries which are FQSed. So instead of forcing regular remote
subplan on such queries, we are adding support for rescan of RemoteQuery node.

Patch by Senhu <[email protected]>

Do not FQS NextValueExpr

The target datanode must be determined after computing the next value. So
let is go through regular planning. This fixes couple of regression failures.

Add missing sys/wait.h include to pgxc_monitor

Without this include, the build on FreeBSD fails due to missing
definition of WEXITSTATUS.

Make make_signature fail if any of the commands fails

The make_signature executes a number of commands, but does not check
return values. While the commands are simple and unlikely to fail,
add 'set -e' to prevent strange failures if that ever happens.

Use sed instead of ex in make_signature script

The make_signature script was using ex, which is part of vi editor and
seems to be less portable than sed, particularly when considering BSD
systems (e.g. FreeBSD). It lacks some of the GNU/Linux improvements,
causing failures of the script. We also do not check existence of the
command in configure, so it may be missing entirely.

Switching to sed fixes both those issues - it seems more portable, and
we already check it's availability in configure.

Patch contributed by John Schneider <[email protected]>,
additional comments and input by Jov <[email protected]>.

Fix portals test case

Accept expected output changes which were missed because we've an alternate
expected output file which is not merged automatically. The changes simply
include an additional Project node in the explain node.

Fix insert test case

Various things are done to ensure that the test case passes. Some of these
changes are not truly correct because we might not be testing what the original
test case was supposed to test, but given the limitations that we've imposed on
partition table column positions etc, this is inevitable

- accept some output changes because certain features (such as triggers) not
supported.
- make changes to column ordering so that partitions can be attached
- avoid dropping/adding columns which will change column ordering
- accept additional information displayed by \d+ command

Cast ExecRemoteQuery parameters to (PlanState *) in contrib

Commit d66ec8f444000f861fc3b35e0c65adbd74fd434c fixed ExecRemoteQuery
calls by explicitly casting the parameter to (PlanState *). This commit
does the same thing for calls in stormstats contrib module.

Make sure coordinator_lxid is formatted as %u and not %d

As the coordinator_lxid is uin32, so make sure we use %u to format it
(e.g. when sending it to remote nodes as string) and not just %d.

Define coordinator_lxid GUC as unsigned integer

The coordinator_lxid GUC is internally stored as uint32, but was defined
as plaint int32, triggering a compiler warning. It's also unclear what
would happen for transaction IDs outside the signed range (possibly some
strange issues).

This adds a new GUC type (UInt), used only for this one GUC. The patch
is fairly large, but most of it is boilerplate infrastructure to support
the new GUC type. We have considered simpler workarounds (e.g. treating
the GUC as string and converting it to/from uint32 using the GUC hooks,
but this seems much cleaner and tidier.

Make sure ExecRemoteQuery is called with (PlanState *) parameter

gcc 6.4.1 is complaining when ExecRemoteQuery(PlanState *) gets called
with (RemoteSubqueryState*) parameter. This commit adds explicit cast on
a few places to silence the warnings noise.

An alternative fix might be to use (RemoteSubqueryState*), but that does
not quite work as ResponseCombiner needs to keep a pointer to either
ExecRemoteQuery or ExecRemoteSubplan. So the explicit cast seems better.

Handle params correctly within Subplan nodes

We were not dealing with the params in Subplan correctly, thus those params
were not sent to the remote nodes correctly during RemoteSubplan exectution.
This patch fixes that by traversing the Subplan node correctly. The regression
failure in the 'join' test case is addressed too.

Patch by senhu ([email protected])

Generate a DEFAULT clause for identity columns

Recent changes in PG 10 generates a nextval() expression (there was no support
for NextValExpr in ruleutils before that). But that fails on the datanode side
because only DEFAULT values are accepted for identity columns, unless
overridden. This patch restores the XL behaviour, thus helping the regression.

Accept some trivial regression diffs after the last merge

Merge commit '21d304dfedb4f26d0d6587d9ac39b1b5c499bb55'

This is the merge-base of PostgreSQL's master branch and REL_10_STABLE branch.
This should be the last merge from PG's master branch into XL 10 branch.
Subsequent merges must happen from REL_10_STABLE branch

Final pgindent + perltidy run for v10.

Handle elog(FATAL) during ROLLBACK more robustly.

Stress testing by Andreas Seltenreich disclosed longstanding problems that
occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are
trying to execute a ROLLBACK of an already-failed transaction.  In such a
case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction
would skip AbortTransaction and go straight to CleanupTransaction.  This
led to an assert failure in an assert-enabled build (due to the ROLLBACK's
portal still having a cleanup hook) or without assertions, to a FATAL exit
complaining about "cannot drop active portal".  The latter's not
disastrous, perhaps, but it's messy enough to want to improve it.

We don't really want to run all of AbortTransaction in this code path.
The minimum required to clean up the open portal safely is to do
AtAbort_Memory and AtAbort_Portals.  It seems like a good idea to
do AtAbort_Memory unconditionally, to be entirely sure that we are
starting with a safe CurrentMemoryContext.  That means that if the
main loop in AbortOutOfAnyTransaction does nothing, we need an extra
step at the bottom to restore CurrentMemoryContext = TopMemoryContext,
which I chose to do by invoking AtCleanup_Memory.  This'll result in
calling AtCleanup_Memory twice in many of the paths through this function,
but that seems harmless and reasonably inexpensive.

The original motivation for the assertion in AtCleanup_Portals was that
we wanted to be sure that any user-defined code executed as a consequence
of the cleanup hook runs during AbortTransaction not CleanupTransaction.
That still seems like a valid concern, and now that we've seen one case
of the assertion firing --- which means that exactly that would have
happened in a production build --- let's replace the Assert with a runtime
check.  If we see the cleanup hook still set, we'll emit a WARNING and
just drop the hook unexecuted.

This has been like this a long time, so back-patch to all supported
branches.

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

Fix typo

Author: Masahiko Sawada <[email protected]>

doc: Fix logical replication protocol doc detail

Author: Masahiko Sawada <[email protected]>
Reported-by: Kyle Conroy <[email protected]>
Bug: #14775

Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.

Commit 3c163a7fc's original choice to ignore all #define symbols whose
names begin with underscore turns out to be too simplistic.  On Windows,
some Perl installations are built with -D_USE_32BIT_TIME_T, and we must
absorb that or we get the wrong result for sizeof(PerlInterpreter).

This effectively re-reverts commit ef58b87df, which injected that symbol
in a hacky way, making it apply to all of Postgres not just PL/Perl.
More significantly, it did so on *all* 32-bit Windows builds, even when
the Perl build to be used did not select this option; so that it fails
to work properly with some newer Perl builds.

By making this change, we would be introducing an ABI break in 32-bit
Windows builds; but fortunately we have not used type time_t in any
exported Postgres APIs in a long time.  So it should be OK, both for
PL/Perl itself and for third-party extensions, if an extension library
is built with a different _USE_32BIT_TIME_T setting than the core code.

Patch by me, based on research by Ashutosh Sharma and Robert Haas.
Back-patch to all supported branches, as commit 3c163a7fc was.

Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com

Changed ecpg parser to allow RETURNING clauses without attached C variables.

Remove AtEOXact_CatCache().

The sole useful effect of this function, to check that no catcache
entries have positive refcounts at transaction end, has really been
obsolete since we introduced ResourceOwners in PG 8.1.  We reduced the
checks to assertions years ago, so that the function was a complete
no-op in production builds.  There have been previous discussions about
removing it entirely, but consensus up to now was that it had some small
value as a cross-check for bugs in the ResourceOwner logic.

However, it now emerges that it's possible to trigger these assertions
if you hit an assert-enabled backend with SIGTERM during a call to
SearchCatCacheList, because that function temporarily increases the
refcounts of entries it's intending to add to a catcache list construct.
In a normal ERROR scenario, the extra refcounts are cleaned up by
SearchCatCacheList's PG_CATCH block; but in a FATAL exit we do a
transaction abort and exit without ever executing PG_CATCH handlers.

There's a case to be made that this is a generic hazard and we should
consider restructuring elog(FATAL) handling so that pending PG_CATCH
handlers do get run.  That's pretty scary though: it could easily create
more problems than it solves.  Preliminary stress testing by Andreas
Seltenreich suggests that there are not many live problems of this ilk,
so we rejected that idea.

There are more-localized ways to fix the problem; the most principled
one would be to use PG_ENSURE_ERROR_CLEANUP instead of plain PG_TRY.
But adding cycles to SearchCatCacheList isn't very appealing.  We could
also weaken the assertions in AtEOXact_CatCache in some more or less
ad-hoc way, but that just makes its raison d'etre even less compelling.
In the end, the most reasonable solution seems to be to just remove
AtEOXact_CatCache altogether, on the grounds that it's not worth trying
to fix it.  It hasn't found any bugs for us in many years.

Per report from Jeevan Chalke.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/CAM2+6=VEE30YtRQCZX7_sCFsEpoUkFBV1gZazL70fqLn8rcvBA@mail.gmail.com

Reword comment for clarity

Reported by Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoB+ycZ2z-4Ye=6MfQ_r0aV5r6cvVPw4kOyPdp6bHqQoBQ@mail.gmail.com

Fix vertical spanning in table "wait_event Description".

Michael Paquier

Discussion: https://postgr.es/m/CAB7nPqQr3KEQvXeuUNYcm7tDK2Fb9oLUQ8DU0+y0RZEoN_1_gg@mail.gmail.com

Simplify fetch-slot-xmins logic in recovery TAP tests.

Merge wait_slot_xmins() into get_slot_xmins().  At this point the only
place that wasn't doing a wait was the initial-state test, and a wait
there seems pretty harmless.

Michael Paquier

Discussion: https://postgr.es/m/CAB7nPqSp_SLQb2uU7am+sn4V3g1UKv8j3yZU385oAG1cG_BN9Q@mail.gmail.com

Be more thorough about cleaning out gcov litter.

At least on my machine, a run with code coverage enabled produces some
".gcov" files whose names begin with ".".  "rm -f *.gcov" fails to match
those, so they don't get cleaned up by "make clean".  Fix it.

Add regression tests exercising more code paths in nodeLimit.c.

Perusal of the code coverage report shows that the existing regression
test cases for LIMIT/OFFSET don't exercise the nodeLimit code paths
involving backwards scan, empty results, or null values of LIMIT/OFFSET.
Improve the coverage.

Add regression tests exercising the non-hashed code paths in nodeSetop.c.

Perusal of the code coverage report shows that the existing regression
test cases for INTERSECT and EXCEPT seemingly all prefer the SETOP_HASHED
implementation.  Add some test cases in which we force use of the
SETOP_SORTED mode.

doc: Add example for inet vs cidr difference

Reported-by: [email protected]

doc: Update description of rolreplication column

Since PostgreSQL 9.6, rolreplication no longer determines whether a role
can run pg_start_backup() and pg_stop_backup(), so remove that.

Add that this attribute determines whether a role can create and drop
replication slots.

Reported-by: Fujii Masao <[email protected]>

doc: Small wording improvement

Author: Jeff Janes <[email protected]>

pg_upgrade: Clarify one message

Reported-by: Dennis Björklund <[email protected]>

Remove pgbench's restriction on placement of -M switch.

Previously the -M switch had to appear before any switch that directly
or indirectly specified a benchmarking script.  This was both confusing
and inadequately documented, as per gripe from Tatsuo Ishii.  We can
remove the restriction at the cost of making an extra pass over the
lists of SQL commands, which seems like a cheap price (the string scans
themselves likely cost much more).  The change is just to not extract
parameters from the SQL commands until we have finished parsing the
switches and know the final value of -M.

Per discussion, we'll treat this as a low-grade bug fix and sneak it
into v10, rather than holding it for v11.

Tom Lane, reviewed by Tatsuo Ishii and Fabien Coelho

Discussion: https://postgr.es/m/20170802.110328.1963639094551443169[email protected]
Discussion: https://postgr.es/m/10208.1502465077@sss.pgh.pa.us

Remove uses of "slave" in replication contexts

This affects mostly code comments, some documentation, and tests.
Official APIs already used "standby".

Reject use of ucol_strcollUTF8() before ICU 53

Various bugs can cause crashes, so don't use that function before ICU
53.  It will fall back to the code path used for other encodings.

Since we now tie the function availability to an ICU version, we don't
need the configure test anymore.  That also resolves the issue that the
test result was previously hardcoded for Windows.

researched by Daniel Verite <[email protected]>, Peter Geoghegan
<[email protected]>, Tom Lane <[email protected]>

Discussion: https://www.postgresql.org/message-id/flat/f1438ec6-22aa-4029-9a3b-26f79d330e72%40manitou-mail.org

Fix order of ICU_CFLAGS

It must be before CPPFLAGS so that an ICU installation in a nonstandard
path can take precedence over one in the system path.

Improve the error message when creating an empty range partition.

The previous message didn't mention the name of the table or the
bounds.  Put the table name in the primary error message and the
bounds in the detail message.

Amit Langote, changed slightly by me.  Suggestions on the exac
phrasing from Tom Lane, David G. Johnston, and Dean Rasheed.

Discussion: http://postgr.es/m/CA+Tgmoae6bpwVa-1BMaVcwvCCeOoJ5B9Q9-RHWo-1gJxfPBZ5Q@mail.gmail.com

Make some more improvements to parallel query documentation.

Many places that mentioned only Gather should also mention Gather
Merge, or should be phrased in a more neutral way.  Be more clear
about the fact that max_parallel_workers_per_gather affects the number
of workers the planner may want to use.  Fix a typo.  Explain how
Gather Merge works.  Adjust wording around parallel scans to be a bit
more clear.  Adjust wording around parallel-restricted operations for
the fact that uncorrelated subplans are no longer restricted.

Patch by me, reviewed by Erik Rijkers

Discussion: http://postgr.es/m/CA+TgmoZsTjgVGn=ei5ht-1qGFKy_m1VgB3d8+Rg304hz91N5ww@mail.gmail.com

Fix typo in comment.

Etsuro Fujita

Discussion: http://postgr.es/m/5f794b91-67df-1ac6-8a4f-069f8e8e169d@lab.ntt.co.jp

pgstatindex: Insert some casts to prevent overflow.

This could cause hash indexes to report greater than 100% free space.

Ashutosh Sharma, reviewed by Amit Kapila

Discussion: http://postgr.es/m/CAE9k0PnCKfg-ZK1CwGZJPF1yKcG2A=GUgC3BMdNMzLAXVOo4Eg@mail.gmail.com

Remove incorrect assertion in clog.c

We must advance the oldest XID that can be safely looked up in clog
*before* truncating CLOG, and the oldest XID that can't be reused
*after* truncating CLOG.  This assertion, and the accompanying
comment, are confused; remove them.

Reported by Neha Sharma.

Discussion: http://postgr.es/m/CANiYTQumC3T=UMBMd1Hor=5XWZYuCEQBioL3ug0YtNQCMMT5wQ@mail.gmail.com

Fix handling of container types in find_composite_type_dependencies.

find_composite_type_dependencies correctly found columns that are of
the specified type, and columns that are of arrays of that type, but
not columns that are domains or ranges over the given type, its array
type, etc.  The most general way to handle this seems to be to assume
that any type that is directly dependent on the specified type can be
treated as a container type, and processed recursively (allowing us
to handle nested cases such as ranges over domains over arrays ...).
Since a type's array type already has such a dependency, we can drop
the existing special case for the array type.

The very similar logic in get_rels_with_domain was likewise a few
bricks shy of a load, as it supposed that a directly dependent type
could *only* be a sub-domain.  This is already wrong for ranges over
domains, and it'll someday be wrong for arrays over domains.

Add test cases illustrating the problems, and back-patch to all
supported branches.

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

Prevent passing down MAKELEVEL/MAKEFLAGS from non-GNU make to GNU make.

FreeBSD's make, for one, sets the MAKELEVEL environment variable when
invoking commands.  In the special Makefile we provide to hand off control
from a non-GNU make to GNU make, this causes GNU make to think it is a
child make invocation rather than top-level.  That interferes with the hack
added in commit dcae5facc to cause the temp-install tree to be made only by
the top-level invocation of gmake.  Unset the variable to prevent that.

Likewise unset MAKEFLAGS, which FreeBSD's make also sets, and which could
easily confuse gmake.  There are no reports of actual trouble from that,
but it seems better to be proactive.

Back-patch to 9.5 where dcae5facc came in.

Thomas Munro, hacked a bit more by me

Discussion: https://postgr.es/m/CAEepm=1ueww35AXTkt1A3gyzZUqv5XCzh8RUNvJZAQAW=eOhVw@mail.gmail.com

doc: Add missing pieces to logical replication protocol doc

Reported-by: Kyle Conroy <[email protected]>