Properly deallocate prepared statements on the remote node when user makes such
request

Per report by Vamshi Reddy

Fix a memory leak in GTM proxy

When two lists are concatnated, we might leak header of the second list since
only the list cells are concatnated. We must be careful not to free the list if
list_concat returned the to-be-concatnated list as-is.

Honour shared queue refcount while deciding to remove it from hash table when
producer unbinds

It's possible that another execution of the portal may start just while we are
unbinding. Hence premature removal of the shared queue should be avoided.

Make minimum values of shared_queues and shared_queue_size GUC parameters
dependent on other settings

shared_queue_size is dependent on the number of datanodes in the cluster since
each datanode may attach itself as a consumer of the shared queue. So the
shared_queue_size now signifies per-datanode value and the actual value used
will be (max_datanodes * shared_queue_size). Existing users should modify their
settings after taking this into consideration.

Similarly, shared_queues highly depends on the number of concurrent queries. We
now conservatively set this to at least 1/4th of max_connections or user
specified value, whichever is higher.

Add a ref count mechanism to deal with situations where a Shared Queue is
acquired but never bound by any of the node, thus causing leakage

To be honest, this area requires further work. The way things are currently
setup, producer and consumers all bind to a shared queue, but only producer
eventually unbinds. The implementation has logic to wait out for consumers
before destroying a shared queue. While this is okay, a more defined entry and
exit points are required for producer and consumers.

The code also today relies on timeouts to handle the case where a consumer
never binds to a shared queue, thus causing large delays. These delays are more
prominent for very short queries.

Correct shared memory size calculation for Shared Queue hashtable.

Extend CLog, Subtrans log and CommitTsLog appropriately when an XID is received
from a remote node

Fix a nasty bug that was zeroing out clog and subtrans pages, thus causing
various sorts of data corruptions.

The bug dates back to the XC days, but probably became prominent in XL because
of certain recent changes. In XC/XL, a node may not see all the XIDs and hence
clog/subtrans log must be extended whenever a new XID crosses the previously
seen page boundary. We do this by comparing the pageno where the new XID maps
with the latest_page_no as stored in the shared SLRU data structure. But to
handle XID wrap-arounds, we added a check for difference in number of pages to
be less than CLOG_WRAP_CHECK_DELTA, which was incorrectly defined as
(2^30 / CLOG_XACTS_PER_PAGE). Note that "^" is a logical XOR operator in C and
hence this was returned a very small number of 28, thus causing incorrect
zeroing of pages if ExtendCLOG is called with an XID which is older than what
28 clog pages can hold. All such transactions would suddenly be marked as
aborted, resulting in removal of perfectly valid tuples.

This patch fixes the mess by just relying on built-in routines for checking
XID wrap-arounds.

I also found another issue while working on this. We must not only zero the
page at hand, but also all intermediate pages because we won't this opportunity
later if an intermediate XID is seen.

In our test setup, this seems to help some of the recent reports of data
corruption, including "missing attributes" errors.

It may happen that we try to read the status of a transaction
in clog before the page has been committed.

There are places in the code that try to extend clog,
but here we simply just do one retry if it looks like
we failed to read the desired page.

Stamp Postgres-XL 9.5r1

Update release notes and also correct product name to Postgres-XL 9.5r1

Fix yet another memory leak in the shared queue producer path.

Fix another memory leak in executor.

Plug a memory leak that might help OOM situations in ALTER TABLE .. ADD NODE
case

Report by Florian Iragne

Test no more uses 'start' command for gtm slave

'pgxc_ctl start' command is no more needed to start
gtm slave, with recent code changes.

Don't use special marker "none" while updating max_wal_senders in
postgresql.conf via pgxc_ctl.

Instead use "0" if the variable is not set or set to "none"

Make 'help add' more explanatory

Help user to supply 'slave_name' in
'pgxc_ctl add gtm slave', different from others
where original node name is expected.

Fixes #85

Avoid removing directories for some pgxc_ctl calls, just as an added protection
if user makes a mistake

Check for 'status' and not return value of waitpid() function

Suppress the message hinting to start coordinator/datanode/gtm server at the
end of initdb/initgtm when the commands are run via pgxc_ctl

This can be confusing to the user. We use an environment varibale
PGXC_CTL_SILENT to silence the message instead of adding a new option.

Add check against accidental start of GTM with an XID lower than what it's
saved in its control file.

User must now explicitly specify -f option to forcefully start GTM with the
given value. This should protect users from incorrect usage of the -x option
(like we saw in a recent bug report)

Fix a typo in the log message during datanode failover

Reduce log level for a message during initdb

Add an alternate expected file for aggregates test on sunos

Patch by Patrick Sodré

Make changes and bug fixes to let compilation and regression run on smartos

We don't yet officially support the platform, given very little testing done so
far on this platform. But we don't stop others to doing it either. So
committing these changes upstream.

Reports, investigation and patches by Patrick Sodré.

Do not add a spurious ';' when not cleaning WAL directory for a datanode

Test: Change command to start GTM standby.

Use temporary PGXC_CTL_HOME for test.

Add test for GTM standby

Modify tests

Remove cluster-cleanup at start.
Extract PGXC_CTL_HOME from ENV.

Extend the array for various slave variables to match the size of the master
array.

This fixes the problem when a slave for only one master datanode or coordinator
is added, as demonstrated by the tap tests

extendVar should only reset val_used only when newSize is greater than the
current value of val_used

Accept -m option to pgxc_ctl, but let "stop" command handle the rest

Correct a comment added to pgxc_ctl.conf upon coordinator master addition

Merge upto PostgreSQL 9.5.2 (730811c7d1600b92d4bcb91ac66d2206cf3a06ef)

Add test for pgxc_ctl minimal config

Add some more cleanup to TAP tests.

Stamp Postgres-XL 9.5r1beta2

Avoid pre-mature line truncation in the auto generated INSTALL file

Improve draft release notes for upcoming beta2 release

In the installation guide, use datanode names that are consistent with what we
use in regression tests, for sanity.

Add missing steps to create information about the coordinator node on the
datanodes in installation guide

Stamp 9.5.2.

Last-minute updates for release notes.

Security: CVE-2016-2193, CVE-2016-3065

Add missing checks to some of pageinspect's BRIN functions

brin_page_type() and brin_metapage_info() did not enforce being called
by superuser, like other pageinspect functions that take bytea do.
Since they don't verify the passed page thoroughly, it is possible to
use them to read the server memory with a carefully crafted bytea value,
up to a file kilobytes from where the input bytea is located.

Have them throw errors if called by a non-superuser.

Report and initial patch: Andreas Seltenreich

Security: CVE-2016-3065

Draft release notes which includes bug fixes and improvements since r1beta1 release

Add TAP test for pgxc_ctl

Test add/remove nodes and replicas

Reset plan->row_security_env and planUserId

In the plancache, we check if the environment we planned the query under
has changed in a way which requires us to re-plan, such as when the user
for whom the plan was prepared changes and RLS is being used (and,
therefore, there may be different policies to apply).

Unfortunately, while those values were set and checked, they were not
being reset when the query was re-planned and therefore, in cases where
we change role, re-plan, and then change role again, we weren't
re-planning again.  This leads to potentially incorrect policies being
applied in cases where role-specific policies are used and a given query
is planned under one role and then executed under other roles, which
could happen under security definer functions or when a common user and
query is planned initially and then re-used across multiple SET ROLEs.

Further, extensions which made use of CopyCachedPlan() may suffer from
similar issues as the RLS-related fields were not properly copied as
part of the plan and therefore RevalidateCachedQuery() would copy in the
current settings without invalidating the query.

Fix by using the same approach used for 'search_path', where we set the
correct values in CompleteCachedPlan(), check them early on in
RevalidateCachedQuery() and then properly reset them if re-planning.
Also, copy through the values during CopyCachedPlan().

Pointed out by Ashutosh Bapat.  Reviewed by Michael Paquier.

Back-patch to 9.5 where RLS was introduced.

Security: CVE-2016-2193

Correct URL to Postgres-XL online release notes

Remove a reference to sourceforge project page now that we don't use it anymore

Correct Copyright years

Correctly use Postgres-XL instead of PostgreSQL for reporting "make" status

Correctly specify HASH_BLOBS while using nodeOid as a key for pooler hash
tables.

Without this, we were incorrectly using the default string copy/compare
functions, thus later breaking things.

Use a non-zero default value for max_wal_senders on coordinator and datanode
master

Translation updates

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 0ffb9ae13cb7e2a9480ed8ee34071074bd80a7aa

Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21.

pg_rewind: fsync target data directory.

Previously pg_rewind did not fsync any files. That's problematic, given
that the target directory is modified. If the database was started
afterwards, 2ce439f33 luckily already caused the data directory to be
synced to disk at postmaster startup; reducing the scope of the problem.

To fix, use initdb -S, at the end of the pg_rewind run. It doesn't seem
worthwhile to duplicate the code into pg_rewind, and initdb -S is
already used that way by pg_upgrade.

Reported-By: Andres Freund
Author: Michael Paquier, somewhat edited by me
Discussion: 20160310034352[email protected]
    CAB7nPqSytVG1o4S3S2pA1O=692ekurJ+fckW2PywEG3sNw54Ow@mail.gmail.com
Backpatch: 9.5, where pg_rewind was introduced

pg_rewind: Close backup_label file descriptor.

This was a relatively harmless leak, as createBackupLabel() is only
called once per pg_rewind invocation.

Author: Michael Paquier
Reported-By: Michael Paquier
Discussion: CAB7nPqRnOw30gOXe2_SPLjh37bgm4V+txbYAPwoXb97nGQ297w@mail.gmail.com
Backpatch: 9.5, where pg_rewind was introduced

Change various Gin*Is* macros to return 0/1.

Returning the direct result of bit arithmetic, in a macro intended to be
used in a boolean manner, can be problematic if the return value is
stored in a variable of type 'bool'. If bool is implemented using C99's
_Bool, that can lead to comparison failures if the variable is then
compared again with the expression (see ginStepRight() for an example
that fails), as _Bool forces the result to be 0/1. That happens in some
configurations of newer MSVC compilers.  It's also problematic when
storing the result of such an expression in a narrower type.

Several gin macros have been declared in that style since gin's initial
commit in 8a3631f8d86.

There's a lot more macros like this, but this is the only one causing
regression test failures; and I don't want to commit and backpatch a
larger patch with lots of conflicts just before the next set of minor
releases.

Discussion: 20150811154237[email protected]
Backpatch: All supported branches

Modernize zic's test for valid timezone abbreviations.

We really need to sync all of our IANA-derived timezone code with upstream,
but that's going to be a large patch and I certainly don't care to shove
such a thing into stable branches immediately before a release.  As a
stopgap, copy just the tzcode2016c logic that checks validity of timezone
abbreviations.  This prevents getting multiple "time zone abbreviation
differs from POSIX standard" bleats with tzdata 2014b and later.

Update time zone data files to tzdata release 2016c.

DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,
Astrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections
for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).

As of 2015b, the keepers of the IANA timezone database started to use
numeric time zone abbreviations (e.g., "+04") instead of inventing
abbreviations not found in the wild like "ASTT".  This causes our rather
old copy of zic to whine "warning: time zone abbreviation differs from
POSIX standard" several times during "make install".  This warning is
harmless according to the IANA folk, and I don't see any problems with
these abbreviations in some simple tests; but it seems like now would be
a good time to update our copy of the tzcode stuff.  I'll look into that
soon.

pqsignal.c now comes from src/port and that must be used to create a symlink
while building initgtm.

Do not turn hot_standby in coordinator/datanode slaves since its not supported.

We'd earlier turned that on so that PQping() can check status of standbys. But
that clearly creates bigger trouble and standbys may just stop working. So add
a new mechanism to ping slave nodes by using pg_ctl

Disable abbreviated keys for string-sorting in non-C locales.

Unfortunately, every version of glibc thus far tested has bugs whereby
strcoll() ordering does not match strxfrm() ordering as required by
the standard.  This can result in, for example, corrupted indexes.
Disabling abbreviated keys in these cases slows down non-C-collation
string sorting considerably, but there seems to be no practical
alternative.  Users who are confident that their libc implementations
are solid in this regard can re-enable the optimization by compiling
with TRUST_STRXFRM.

Users who have built indexes using PostgreSQL 9.5 or PostgreSQL 9.5.1
should REINDEX if there is a possibility that they may have been
affected by this problem.

Report by Marc-Olaf Jaschke.  Investigation mostly by Tom Lane, with
help from Peter Geoghegan, Noah Misch, Stephen Frost, and me.  Patch
by me, reviewed by Peter Geoghegan and Tom Lane.

Code review for error reports in jsonb_set().

User-facing (even tested by regression tests) error conditions were thrown
with elog(), hence had wrong SQLSTATE and were untranslatable.  And the
error message texts weren't up to project style, either.

Fix unsafe use of strtol() on a non-null-terminated Text datum.

jsonb_set() could produce wrong answers or incorrect error reports, or in
the worst case even crash, when trying to convert a path-array element into
an integer for use as an array subscript.  Per report from Vitaly Burovoy.
Back-patch to 9.5 where the faulty code was introduced (in commit
c6947010ceb42143).

Michael Paquier

Change comment to describe correct lock level used

Fix EvalPlanQual bug when query contains both locked and not-locked rels.

In commit afb9249d06f47d7a, we (probably I) made ExecLockRows assign
null test tuples to all relations of the query while setting up to do an
EvalPlanQual recheck for a newly-updated locked row.  This was sheerest
brain fade: we should only set test tuples for relations that are lockable
by the LockRows node, and in particular empty test tuples are only sensible
for inheritance child relations that weren't the source of the current
tuple from their inheritance tree.  Setting a null test tuple for an
unrelated table causes it to return NULLs when it should not, as exhibited
in bug #14034 from Bronislav Houdek.  To add insult to injury, doing it the
wrong way required two loops where one would suffice; so the corrected code
is even a bit shorter and faster.

Add a regression test case based on his example, and back-patch to 9.5
where the bug was introduced.

Check if gtm/gtm_proxy directory has a .pid file before trying to stop the
server.

Before starting or initialising a new GTM/GTM proxy, we first try to stop
running server. But if server is not running, which is the case most often, it
will show an error This avoids those unnecessary error messages

Correct example in the tutorial.

We don't support SRF in VALUES clause. They must be used via subqueries.
Report by Ernst-Georg Schmid

Remove dependency on psed for MSVC builds.

Modern Perl has removed psed from its core distribution, so it might not
be readily available on some build platforms. We therefore replace its
use with a Perl script generated by s2p, which is equivalent to the sed
script. The latter is retained for non-MSVC builds to avoid creating a
new hard dependency on Perl for non-Windows tarball builds.

Backpatch to all live branches.

Michael Paquier and me.

Fix phony .PHONY.

A couple makefiles had misspelled the magic .PHONY target as PHONY.

docs: Fix typo'd brin_summarize_new_values

I wrote "brin_summarize_new_pages" instead, in docs as well as in the
commit message of commit ac443d1034d9.

Bug: #14030
Reported-By: Chris Pacejo

Remove useless double calls of make_parsestate().

Aleksander Alekseev

Fix assorted breakage in to_char()'s OF format option.

In HEAD, fix incorrect field width for hours part of OF when tm_gmtoff is
negative.  This was introduced by commit 2d87eedc1d4468d3 as a result of
falsely applying a pattern that's correct when + signs are omitted, which
is not the case for OF.

In 9.4, fix missing abs() call that allowed a sign to be attached to the
minutes part of OF.  This was fixed in 9.5 by 9b43d73b3f9bef27, but for
inscrutable reasons not back-patched.

In all three versions, ensure that the sign of tm_gmtoff is correctly
reported even when the GMT offset is less than 1 hour.

Add regression tests, which evidently we desperately need here.

Thomas Munro and Tom Lane, per report from David Fetter

Fix "pg_bench -C -M prepared".

This didn't work because when we dropped and re-established a database
connection, we did not bother to reset session-specific state such as
the statements-are-prepared flags.

The st->prepared[] array certainly needs to be flushed, and I cleared a
couple of other fields as well that couldn't possibly retain meaningful
state for a new connection.

In passing, fix some bogus comments and strange field order choices.

Per report from Robins Tharakan.

Avoid incorrectly indicating exclusion constraint wait

INSERT ... ON CONFLICT's precheck may have to wait on the outcome of
another insertion, which may or may not itself be a speculative
insertion.  This wait is not necessarily associated with an exclusion
constraint, but was always reported that way in log messages if the wait
happened to involve a tuple that had no speculative token.

Initially discovered through use of ON CONFLICT DO NOTHING, where
spurious references to exclusion constraints in log messages were more
likely.

Patch by Peter Geoghegan.
Reviewed by Julien Rouhaud.

Back-patch to 9.5 where INSERT ... ON CONFLICT was added.

Fix typos in comments

Cope if platform declares mbstowcs_l(), but not locale_t, in <xlocale.h>.

Previously, we included <xlocale.h> only if necessary to get the definition
of type locale_t.  According to notes in PGAC_TYPE_LOCALE_T, this is
important because on some versions of glibc that file supplies an
incompatible declaration of locale_t.  (This info may be obsolete, because
on my RHEL6 box that seems to be the *only* definition of locale_t; but
there may still be glibc's in the wild for which it's a live concern.)

It turns out though that on FreeBSD and maybe other BSDen, you can get
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from
<xlocale.h>.  This was leaving us compiling calls to mbstowcs_l() and
friends with no visible prototype, which causes a warning and could
possibly cause actual trouble, since it's not declared to return int.

Hence, adjust the configure checks so that we'll include <xlocale.h>
either if it's necessary to get type locale_t or if it's necessary to
get a declaration of mbstowcs_l().

Report and patch by Aleksander Alekseev, somewhat whacked around by me.
Back-patch to all supported branches, since we have been using
mbstowcs_l() since 9.1.

Remove an obselete file

Rename RelationLocInfo->nodeList to RelationLocInfo->rl_nodeList to avoid using
such a common name for a very important structure member

Re-add incorrectly removed call to consume txn_count during compiler warning
cleanups

Add support for json_agg() pushdown

This patch adds a collection function for json_agg() aggregate. Also use a
specific json_agg_state type for the internal agg state so that corresponding
in/out functions can be specified for transition values to be passed around
from one node to another

Add missing NULL terminator to list_SECURITY_LABEL_preposition[].

On the machines I tried this on, pressing TAB after SECURITY LABEL led to
being offered ON and FOR as intended, plus random other keywords (varying
across machines).  But if you were a bit more unlucky you'd get a crash,
as reported by [email protected] in bug #14019.

Seems to have been an aboriginal error in the SECURITY LABEL patch,
commit 4d355a8336e0f226.  Hence, back-patch to all supported versions.
There's no bug in HEAD, though, thanks to our recent tab-completion
rewrite.

Fix a compiler warning about mixing of code and declarations

Aggregates with ORDER BY clause cannot be shipped to the datanode.

A query such as "SELECT sum(x ORDER BY x) FROM tab" must not be shipped to the
remote side since the transition function must receive tuples in the specified
order. While it does not make much sense in this example, there could be other
aggregares, such as json_agg, where ordering could matter

Fix memory leak in repeated GIN index searches.

Commit d88976cfa1302e8d removed this code from ginFreeScanKeys():
- if (entry->list)
- pfree(entry->list);
evidently in the belief that that ItemPointer array is allocated in the
keyCtx and so would be reclaimed by the following MemoryContextReset.
Unfortunately, it isn't and it won't.  It'd likely be a good idea for
that to become so, but as a simple and back-patchable fix in the
meantime, restore this code to ginFreeScanKeys().

Also, add a similar pfree to where startScanEntry() is about to zero out
entry->list.  I am not sure if there are any code paths where this
change prevents a leak today, but it seems like cheap future-proofing.

In passing, make the initial allocation of so->entries[] use palloc
not palloc0.  The code doesn't depend on unused entries being zero;
if it did, the array-enlargement code in ginFillScanEntry() would be
wrong.  So using palloc0 initially can only serve to confuse readers
about what the invariant is.

Per report from Felipe de Jesús Molina Bravo, via Jaime Casanova in
<CAJGNTeMR1ndMU2Thpr8GPDUfiHTV7idELJRFusA5UXUGY1y-eA@mail.gmail.com>

Report memory context stats upon out-of-memory in repalloc[_huge].

This longstanding functionality evidently got lost in commit
3d6d1b585524aab6.  Noted while studying an OOM report from Jaime
Casanova.  Backpatch to 9.5 where the bug was introduced.

Get rid of scribbling on a const variable in psql's print.c.

Commit a2dabf0e1dda93c8 had the bright idea that it could modify a "const"
global variable if it merely casted away const from a pointer.  This does
not work on platforms where the compiler puts "const" variables into
read-only storage.  Depressingly, we evidently have no such platforms in
our buildfarm ... an oversight I have now remedied.  (The one platform
that is known to catch this is recent OS X with -fno-common.)

Per report from Chris Ruprecht.  Back-patch to 9.5 where the bogus
code was introduced.

Fix several compiler warnings

Do not compare unsigned integer for "< 0"

Explicitly cast pthread_t to int for logging purposes

fix missing prototypes (and 'implicit declaration' warning)

remove functions that are not used (or defined)

add missing declarations of timeval/rusage structs

fix declarations that discard 'const' modifier from pointers

get rid of GTMGetFirstClientIdentifier (unused)

function not used or even defined in a header file

fix a few violations of ISO C90 (mixed code/declarations)

Interestingly ';;' confuses the compiler enough to emit this warning.

eliminate variables that are not used at all

eliminate variables that are only set (but not used)

fix missing ExceptionalCondition prototype / return type

During compilation, there's like a zillion warnings about missing
prototype of ExceptionalCondition. Of course, in regular postgres
this is defined in postgres.h like this:

    void ExceptionalCondition(...)

but in XL apparently some places use Assert it without willing to
include the whole postgres.h (not sure why). So there's a copy of
the function in src/gtm/common/assert.c, but there's no prototype
in src/include/gtm/assert.h, thus the complaints.

Adding the prototype to the header file however reveals another
problem, as the function in src/gtm/common/assert.c is defined
like this

    int ExceptionalCondition(...)

with a rather wonky explanation about TrapMacro(). So this would
fail to compile when a file ends up g both header files, like for
example src/gtm/client/gtm_client.c. (Fun fact: gtm_client.c does
not really need the include at all.)

Therefore the best solution at this point seems to be to simply
change the return type in assert.c to void (and get rid of the
rather suspicious explanation above the function), and add the
prototype into src/include/gtm/assert.c. This way the prototype
matches the one from postgres.h, there's no conflict and the
warnings disappear.

In the long term however, the right solution seems to be simply
removing the redundancy by dropping the gtm copy of the function.

Document BRIN a bit more thoroughly

The chapter "Interfacing Extensions To Indexes" and CREATE OPERATOR
CLASS reference page were missed when BRIN was added.  We document
all our other index access methods there, so make sure BRIN complies.

Author: Álvaro Herrera
Reported-By: Julien Rouhaud, Tom Lane
Reviewed-By: Emre Hasegeli
Discussion: https://www.postgresql.org/message-id/56CF604E.9000303%40dalibo.com
Backpatch: 9.5, where BRIN was introduced