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

Set XactTopTransactionId also on receiving XID from a datanode

Send a single command-complete message from remote coordinator or datanode

When a client sends a multi-command string for execution, Postgres server
executes each command separately and sends a command-complete for each command.
The coordinator is not well equipped though to handle this since it sends the
whole query string as it is to the datanode and expects a single
command-complete.

What we need is a mechanism where coordinator sends each command separately to
the datanode. It already parses multi-command string into multiple parse-trees.
Earlier we did not have mechanism to deparse utility commands, but IIRC we now
have that. So we should look at using that infrastructure

Add a flag to the latest snapshot from GTM when situation demands.

Catalog scans for example require the latest snapshot to see the latest changes
to the catalogs. This patch fixes the problem with catalog scans

Assign GTM-generated XID for an auto-commit, single datanode transaction which
won't receive a coordinator pushed down XID neither will have a transaction
block active

Correct '=' to '==' in an assertion

Drop datanode/coordinator connections while handling transaction aborts,
overriding persistent_datanode_connections setting

Add a developer GUC "enable_datanode_row_triggers" to allow ROW TRIGGERS to be
executed on the datanodes.

This must be used with caution. Postgres-XL does not officially support
triggers yet. One of the reasons for not supporting triggers is that a trigger
function executed on a datanode may not have access to all the required data
since the data may not reside on the datanode. But if users are confident that
the triggers can be safely executed on the datanode, they may turn this GUC on.
Still since the feature is not well tested, we don't recommend users to use
this without thorough testing and knowing consequences.

Merge remote-tracking branch 'remotes/PGSQL/REL9_5_STABLE' into XL9_5_STABLE

Add a developer-GUC 'gloabl_snapshot_source' to allow informed users to
override the way snapshots are computed.

The default value of the GUC is 'gtm' which means that snapshots are always
generated on the GTM so that we get a full and correct view of the currently
running transactions. But with this developer-GUC we now allow users to
override that and work with a coordinator generated snapshots. This can be
especially useful for read-only queries which now don't need to talk to the
GTM. If the snapshots can also be taken locally on a coordinator, this will
even further reduce the round-trips to the GTM. Of course, this can lead to
consistency issues because a coordinator may not be aware of all the
transactions currently running on the XL cluster, especially in a
multi-coordinator setup where different coordinators could be running different
transactions without knowing about each other's activity. But even in a single
coordinator setup, some transactions may start on a datanode and coordinator
may not know about them or may only know quite late.

Its advised that this feature must be used with caution and after due
consideration of the effects

Allow on-demand assignment of XID, even on a datanode

Till now, we used to aggressively assign transaction identifiers on the
coordinator, even if the transaction may not actually need one because
it does not do any write operation. PostgreSQL has improved this case many
years back with the usage of Virtual XIDs. But since in Postgres-XL, if a
read-looking SELECT statement later does some write opreation, it would be too
late to assign a transaction identifier when the query is running on the
datanode. But such aggressive XID assignment causes severe performance
problems, especially for read-only queries.

We now solve this by assigning XID on-demand for SELECT queries. If a datanode
ever needs an XID, it will talk to the GTM with a global session identifier
which remains unique for a given global transaction on all nodes. GTM can then
correlate multiple BEGIN TXN requests for the same global transaction and
return the already assigned identifer, instead of opening a new transaction
every time.

For DML queries, we still acquire XID on the coordinator. This will be a loss
if DML ends up not doing any write operation. But since its not going to be a
very regular scenario, it makes sense to pre-acquire an XID. More tests are
required though to verify this

Forget connection combiner before receving pending messages during cleanup

Do not use RemoteSubplan for simple Result plan which can be evaluated on any
node

This should reduce connections for a single INSERT statements

Reduce logging level for tuplestore_end message

Avoid repeated invalidation on plans because of mismatch in search_path

Introduce a cluster monitor lock to avoid a race condition between spanshot
fetch and xmin reporting

Reduce logging level for couple of messages

Ouch. Forgot to take this half-cooked and incorrect code in the previous commit

Acquire the right lock for updating latestCompletedXid.

Also make sure that the latestCompletedXid is updated on the nodes irrespective
of whather report-xmin returns success or failure

Rework handling of idle nodes for xmin reporting and calculation

The local value of latestCompletedXid caps the xmin computation on an idle
cluster. So GTM sends back an updated value of latestCompletedXid as part of
report-xmin response. Once latestCompletedXid is updated on the node, the next
iteration will ensure that the local xmin is advanced on an idle server

Cluster Monitor, which is an auxilliary process need not call InitPostgres and
thus should not start a transaction

Reintroduce XC's Fast Query Shipping (FQS) mechanism to improve performance of
simple queries that can be fully shipped to the datanodes

This patch backports some of the FQS code from XC/master branch. We only use
this for simple queries that can be fully executed on the datanodes. But
otherwise queries go through the XL planner/executor. This is showing good
performance improvements for such simple queries. This will also allow us to
support certain missing features such GROUPING SETS on replicated tables or
queries that require no coordinator support for final aggregations. This hasn't
yet tested though

This will cause many regression test case output since the EXPLAIN plan for
FQS-ed queries would look very different.

Avoid deadlock by ensuring that a rd-lock holder does not request another rd or
wr-lock

While its generally safe for threads to acquire same pthread_rwlock in READ
mode multiple times, if there is a writer blocked on the lock, this can cause
deadlock. So avoid that coding practice.

Add debug facility to GTM_RWLock

This can be turned on by #define GTM_LOCK_DEBUG and should be useful for
deadlock detections and other such causes

Use -w option of pg_ctl to wait for the operation to complete

Reduce logging level for a log message added in commit 257588554

Add an user-friendly hint to the (in)famous "Failed to get pooled connection"
error message

At some point we should look at checking various related GUC parameters and
make sure that they have sane values. For example, user may increase
max_connections at the datanodes, but if she forgets to change the
max_pool_size to a more reasonable value, outgoing connections from a
coordinator or a datanode may not be enough, even though the target node can
accept incoming connections. Its generally hard to derive one value from
another because max_pool_size defines limit on outgoing connections from one
node, but max_connections defines the limit on incoming connections. But we can
still provide some useful hints if there is a gross mismatch of values based on
the number of datanodes and coordinators.

Add a cluster monitor postmaster process

Right now the process is responsible for computing the local RecentGlobalXmin
and send periodic updates to the GTM. The GTM then computes a cluster-wide
value of the RecentGlobalXmin and sends it back to all the reporting nodes
(coordinators as well as datanodes). This way GTM does not need to track all
open snapshots in the system, which previously required a transaction to remain
open, even for a read-only operation. While this patch itself may not show
major performance improvements, this will act as a foundation for other major
improvements for transaction handling.

If a node gets disconnected for a long time or stops sending updates to the
GTM, such a node is removed from computation of the RecentGlobalXmin. This is to
ensure that a failed node does not stop advancement of the RecentGlobalXmin
beyond a certain point. Such a node can safely rejoin the cluster as long as
its not using a snapshot with a stale view of the cluster i.e. a snapshot with
xmin less than the RecentGlobalXmin that the GTM is running with.

Free memory allocated for tracking prepared statements.

This fixes a long-standing memory leak in the TopMemoryContext. Surprisingly,
the reason why I started diagnosing the problem is because pgbench -S -c 1
would run significantly slowly with every iteration. The reason turned out be
that AllocSetCheck() will run slower and slower (yeah, I was running with
--enable-cassert like every other developer). That lead me to investigate for
the memory leaks. This patch now fixes that issue and pgbench -S runs at a
consistent speed, even for cassert enabled builds.

Include pg_rusage.h whereever necessary

Do not use READ ONLY transaction while dumping data using pg_dump

We use nextval(sequence) to get a consistent sequence value directly from the
GTM, since sequence values could be catched at different coordinators. But that
requires a RW transaction. Its not ideal for pg_dump to use RW transaction, but
its not terrible either given that its run in a very controlled manner. So
change it that way until we find a more elegant solution

Also fix some assorted issues with pg_dump. It now seems to pass on the
"regression" database after a round of regression run

Add support for all releases newer than 9.2

Initialise root->recursiveOk correcttly.

This was an oversight during the 9.5 merge process, thus breaking WITH
RECURSIVE for replicated and catalog tables. As a side-effect, this also caused
pg_dump to fail.

Check if configuration parametere such as cord/datanode(Specific)ExtraPgHba
exists before trying to read its value

Check for connection before trying to dereference a pointer

Use correct index into GTM proxy array for coordinator failovers

Do not use ereport(ERROR) while cleaning up connections because we could
already be an abort transaction handling, thus causing infinite recursion

Run slaves in hot_standby mode so that we can ping them for monitoring purposes

This actually restores old behaviour of the utility. XL doesn't currently support
read-only queries on the standbys. But without that PQping fails to connect to
the standby. So restore that for now so that pgxc_ctl monitor works for the
slaves

Use whichever coordinator available for running cluster commands

The utility had assumed that the first coordinator at index 0 will always be
available. But that may not be the case when we have actually removed the first
coordinator using "pgxc_ctl remove coordinator master <name>"

Do not try to initialise multi-executor if we are running as a wal sender

pg_basebackup had stopped working because of this issue. Should be fixed now

Ensure that the array in extended only when adding new entries and not while
replacing existing ones

This should handle the problem of coord and datanode arrays going haywire when
first or in-between coordinators/datanodes are removed using pgxc_ctl

Wait for the socket to become ready to receive more data before attempting to
write again

We'd seen that coordinator can become CPU bound while loading large chunks of
data. Upon investigation, it was found that the coordinator process keeps
trying to send more data, even though the underlying networking layer is not
yet ready to receive more data, most likely because the kernel send-buffer is
full. Instead of retrying in a tight loop, we should check for socket readiness
and then write more

This should also fix the problem of COPY process running out of memory on the
coordinator (exhibited by "invalid memory alloc request size" error seen during
pg_restore as well as COPY)

Cancel queries on remote connections upon transaction abort

Add more instrumentation options to code

This patch adds two new GUCs, log_gtm_stats and log_remotesubplan_stats to
collect more information about GTM communication stats and remote subplan
stats

Use poll() instead of select() at a few places

Patch by Krzysztof Nienartowicz, with some bug fixes and rework by me

Remove a lot of XC-specific code from the repo.

Per discussion on the developer list, this patch removes a bulk of XC-specific
code which is not relevant in XL. This code was mostly left-over in #ifdef
blocks, thus complicating code-reading, bug fixes and merges. One can always do
a "git diff" with the XC code base to see the exact differences.

We still continue to use #ifdef PGXC and #ifdef XCP interchangeably because of
the way code was written. Something we should change. Also, there is probably
still some more dead code (because files were copied to different place or
because the code is not referenced in XL). This requires another cleanup patch,
but not something I plan to do immediately

Fix typo in docs.

Pallavi Sontakke

Factor out encoding specific tests for json

This lets us remove the large alternative results files for the main
json and jsonb tests, which makes modifying those tests simpler for
committers and patch submitters.

Backpatch to 9.4 for jsonb and 9.3 for json.

Improve documentation of the role-dropping process.

In general one may have to run both REASSIGN OWNED and DROP OWNED to get
rid of all the dependencies of a role to be dropped.  This was alluded to
in the REASSIGN OWNED man page, but not really spelled out in full; and in
any case the procedure ought to be documented in a more prominent place
than that.  Add a section to the "Database Roles" chapter explaining this,
and do a bit of wordsmithing in the relevant commands' man pages.

docs:  add JSONB containment example of a key and empty object

Backpatch through 9.5

docs:  Map operator @> to the proper SGML escape for '>'

Backpatch through 9.5

docs:  clarify JSONB operator descriptions

No catalog bump as the catalog changes are for SQL operator comments.

Backpatch through 9.5

Perform an immediate shutdown if the postpid file is removed.

The postmaster now checks every minute or so (worst case, at most two
minutes) that postmaster.pid is still there and still contains its own PID.
If not, it performs an immediate shutdown, as though it had received
SIGQUIT.

The original goal behind this change was to ensure that failed buildfarm
runs would get fully cleaned up, even if the test scripts had left a
postmaster running, which is not an infrequent occurrence.  When the
buildfarm script removes a test postmaster's $PGDATA directory, its next
check on postmaster.pid will fail and cause it to exit.  Previously, manual
intervention was often needed to get rid of such orphaned postmasters,
since they'd block new test postmasters from obtaining the expected socket
address.

However, by checking postmaster.pid and not something else, we can provide
additional robustness: manual removal of postmaster.pid is a frequent DBA
mistake, and now we can at least limit the damage that will ensue if a new
postmaster is started while the old one is still alive.

Back-patch to all supported branches, since we won't get the desired
improvement in buildfarm reliability otherwise.

Stamp 9.5beta1.

docs:  update guidelines on when to use GIN and GiST indexes

Report by Tomas Vondra

Backpatch through 9.5

Docs: explain contrib/pg_stat_statements' handling of GC failure.

Failure to perform garbage collection now has a user-visible effect, so
explain that and explain that reducing pgss_max is the way to prevent it.
Per gripe from Andrew Dunstan.

Fix insufficiently-portable regression test case.

Some of the buildfarm members are evidently miserly enough of stack space
to pass the originally-committed form of this test.  Increase the
requirement 10X to hopefully ensure that it fails as-expected everywhere.

Security: CVE-2015-5289

Translation updates

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 23a52bc86edcd39c3c6b80ee1f7374759c8711f8

Last-minute updates for release notes.

Add entries for security and not-quite-security issues.

Security: CVE-2015-5288, CVE-2015-5289

Remove outdated comment about relation level autovacuum freeze limits.

The documentation for the autovacuum_multixact_freeze_max_age and
autovacuum_freeze_max_age relation level parameters contained:
"Note that while you can set autovacuum_multixact_freeze_max_age very
small, or even zero, this is usually unwise since it will force frequent
vacuuming."
which hasn't been true since these options were made relation options,
instead of residing in the pg_autovacuum table (834a6da4f7).

Remove the outdated sentence. Even the lowered limits from 2596d70 are
high enough that this doesn't warrant calling out the risk in the CREATE
TABLE docs.

Per discussion with Tom Lane and Alvaro Herrera

Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: 9.0- (in parts)

Add regression tests for INSERT/UPDATE+RETURNING

This adds regressions tests which are specific to INSERT+RETURNING and
UPDATE+RETURNING to ensure that the SELECT policies are added as
WithCheckOptions (and should therefore throw an error when the policy is
violated).

Per suggestion from Andres.

Back-patch to 9.5 as the prior commit was.

Prevent stack overflow in query-type functions.

The tsquery, ltxtquery and query_int data types have a common ancestor.
Having acquired check_stack_depth() calls independently, each was
missing at least one call.  Back-patch to 9.0 (all supported versions).

Prevent stack overflow in container-type functions.

A range type can name another range type as its subtype, and a record
type can bear a column of another record type.  Consequently, functions
like range_cmp() and record_recv() are recursive.  Functions at risk
include operator family members and referents of pg_type regproc
columns.  Treat as recursive any such function that looks up and calls
the same-purpose function for a record column type or the range subtype.
Back-patch to 9.0 (all supported versions).

An array type's element type is never itself an array type, so array
functions are unaffected.  Recursion depth proportional to array
dimensionality, found in array_dim_to_jsonb(), is fine thanks to MAXDIM.

Prevent stack overflow in json-related functions.

Sufficiently-deep recursion heretofore elicited a SIGSEGV.  If an
application constructs PostgreSQL json or jsonb values from arbitrary
user input, application users could have exploited this to terminate all
active database connections.  That applies to 9.3, where the json parser
adopted recursive descent, and later versions.  Only row_to_json() and
array_to_json() were at risk in 9.2, both in a non-security capacity.
Back-patch to 9.2, where the json type was introduced.

Oskari Saarenmaa, reviewed by Michael Paquier.

Security: CVE-2015-5289

pgcrypto: Detect and report too-short crypt() salts.

Certain short salts crashed the backend or disclosed a few bytes of
backend memory.  For existing salt-induced error conditions, emit a
message saying as much.  Back-patch to 9.0 (all supported versions).

Josh Kupershmidt

Security: CVE-2015-5288

Apply SELECT policies in INSERT/UPDATE+RETURNING

Similar to 7d8db3e, given that INSERT+RETURNING requires SELECT rights
on the table, apply the SELECT policies as WCOs to the tuples being
inserted.  Apply the same logic to UPDATE+RETURNING.

Back-patch to 9.5 where RLS was added.

Do not write out WCOs in Query

The WithCheckOptions list in Query are only populated during rewrite and
do not need to be written out or read in as part of a Query structure.

Further, move WithCheckOptions to the bottom and add comments to clarify
that it is only populated during rewrite.

Back-patch to 9.5 with a catversion bump, as we are still in alpha.

Re-Align *_freeze_max_age reloption limits with corresponding GUC limits.

In 020235a5754 I lowered the autovacuum_*freeze_max_age minimums to
allow for easier testing of wraparounds. I did not touch the
corresponding per-table limits. While those don't matter for the purpose
of wraparound, it seems more consistent to lower them as well.

It's noteworthy that the previous reloption lower limit for
autovacuum_multixact_freeze_max_age was too high by one magnitude, even
before 020235a5754.

Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: back to 9.0 (in parts), like the prior patch

ALTER TABLE .. FORCE ROW LEVEL SECURITY

To allow users to force RLS to always be applied, even for table owners,
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.

row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump
output is complete (by default).

Also add SECURITY_NOFORCE_RLS context to avoid data corruption when
ALTER TABLE .. FORCE ROW SECURITY is being used. The
SECURITY_NOFORCE_RLS security context is used only during referential
integrity checks and is only considered in check_enable_rls() after we
have already checked that the current user is the owner of the relation
(which should always be the case during referential integrity checks).

Back-patch to 9.5 where RLS was added.

Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.

Improve contrib/pg_stat_statements' handling of garbage collection failure.

If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se.  We used to leave
things alone and hope for better luck next time, but the problem is that
the file is only going to get bigger and even harder to slurp into memory.
Better to do something that will get us out of trouble.

Likewise reset the file to empty for any other failure within gc_qtexts().
The previous behavior after a write error was to discard query texts but
not do anything to truncate the file, which is just weird.

Also, increase the maximum supported file size from MaxAllocSize to
MaxAllocHugeSize; this makes it more likely we'll be able to do a garbage
collection successfully.

Also, fix recalculation of mean_query_len within entry_dealloc() to match
the calculation in gc_qtexts().  The previous coding overlooked the
possibility of dropped texts (query_len == -1) and would underestimate the
mean of the remaining entries in such cases, thus possibly causing excess
garbage collection cycles.

In passing, add some errdetail to the log entry that complains about
insufficient memory to read the query texts file, which after all was
Jim Nasby's original complaint.

Back-patch to 9.4 where the current handling of query texts was
introduced.

Peter Geoghegan, rather editorialized upon by me

Further twiddling of nodeHash.c hashtable sizing calculation.

On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers.  The simplest way to enforce the limit correctly is to
round max_pointers down to a power of 2 when it isn't one already.

(Note that the constraint to INT_MAX / 2, if it were doing anything useful
at all, is properly applied after that.)

Fix some issues in new hashtable size calculations in nodeHash.c.

Limit the size of the hashtable pointer array to not more than
MaxAllocSize, per reports from Kouhei Kaigai and others of "invalid memory
alloc request size" failures.  There was discussion of allowing the array
to get larger than that by using the "huge" palloc API, but so far no proof
that that is actually a good idea, and at this point in the 9.5 cycle major
changes from old behavior don't seem like the way to go.

Fix a rather serious secondary bug in the new code, which was that it
didn't ensure nbuckets remained a power of 2 when recomputing it for the
multiple-batch case.

Clean up sloppy division of labor between ExecHashIncreaseNumBuckets and
its sole call site.

Disallow invalid path elements in jsonb_set

Null path elements and, where the object is an array, invalid integer
elements now cause an error.

Incorrect behaviour noted by Thom Brown, patch from Dmitry Dolgov.

Backpatch to 9.5 where jsonb_set was introduced

Group cluster_name and update_process_title settings together

Document that row_security is a boolean GUC.

Oversight in commit 537bd178c73b1d25938347b17e9e3e62898fc231.
Back-patch to 9.5, like that commit.

Make BYPASSRLS behave like superuser RLS bypass.

Specifically, make its effect independent from the row_security GUC, and
make it affect permission checks pertinent to views the BYPASSRLS role
owns.  The row_security GUC thereby ceases to change successful-query
behavior; it can only make a query fail with an error.  Back-patch to
9.5, where BYPASSRLS was introduced.

Improve errhint() about replication slot naming restrictions.

The existing hint talked about "may only contain letters", but the
actual requirement is more strict: only lower case letters are allowed.

Reported-By: Rushabh Lathia
Author: Rushabh Lathia
Discussion: AGPqQf2x50qcwbYOBKzb4x75sO_V3g81ZsA8+Ji9iN5t_khFhQ@mail.gmail.com
Backpatch: 9.4-, where replication slots were added

Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.

Four related issues:

1) attnos/varnos/resnos for EXCLUDED were out of sync when a column
   after one dropped in the underlying relation was referenced.
2) References to whole-row variables (i.e. EXCLUDED.*) lead to errors.
3) It was possible to reference system columns in the EXCLUDED pseudo
   relations, even though they would not have valid contents.
4) References to EXCLUDED were rewritten by the RLS machinery, as
   EXCLUDED was treated as if it were the underlying relation.

To fix the first two issues, generate the excluded targetlist with
dropped columns in mind and add an entry for whole row
variables. Instead of unconditionally adding a wholerow entry we could
pull up the expression if needed, but doing it unconditionally seems
simpler. The wholerow entry is only really needed for ruleutils/EXPLAIN
support anyway.

The remaining two issues are addressed by changing the EXCLUDED RTE to
have relkind = composite. That fits with EXCLUDED not actually being a
real relation, and allows to treat it differently in the relevant
places. scanRTEForColumn now skips looking up system columns when the
RTE has a composite relkind; fireRIRrules() already had a corresponding
check, thereby preventing RLS expansion on EXCLUDED.

Also add tests for these issues, and improve a few comments around
excluded handling in setrefs.c.

Reported-By: Peter Geoghegan, Geoff Winkless
Author: Andres Freund, Amit Langote, Peter Geoghegan
Discussion: CAEzk6fdzJ3xYQZGbcuYM2rBd2BuDkUksmK=mY9UYYDugg_GgZg@mail.gmail.com,
   CAM3SWZS+CauzbiCEcg-GdE6K6ycHE_Bz6Ksszy8AoixcMHOmsA@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced

doc: Update URLs of external projects