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

Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds

The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.

Detect this combination, and in those cases turn off the generation of
FMA3, per recommendation from the Visual Studio team.

The bug is actually in the CRT shipping with Visual Studio 2013, but
Microsoft have stated they're only fixing it in newer major versions.
The fix is therefor conditioned specifically on being built with this
version of Visual Studio, and not previous or later versions.

Author: Christian Ullrich

Add support for pushdown of Append and MergeAppend nodes.

While dealing with Append and MergeAppend pathnodes, we shouldn't be looking at
the Varno in the "distribution" information because each append subpath comes
from a different relation. So we devise a mechanism to compare distribution
strategies without comparing the Varnos.

Expected outputs of many test cases is also updated because Append and
MergeAppend plans are now pushed down to the datanodes when possible.

"misc" test case exhibited certain failures because of incorrect evaluation of
a "volatile" function on the datanode. This turned out to be an old bug which
should be fixed separately. There were existing failures, masked by incorrect
acceptance of the test output. All such sqls are now disabled from "misc" and
copied to xl_known_bugs. Once the bug related to the volatile functions is
fixed, we would enable those sqls again

Avoid unlikely data-loss scenarios due to rename() without fsync.

Renaming a file using rename(2) is not guaranteed to be durable in face
of crashes. Use the previously added durable_rename()/durable_link_or_rename()
in various places where we previously just renamed files.

Most of the changed call sites are arguably not critical, but it seems
better to err on the side of too much durability.  The most prominent
known case where the previously missing fsyncs could cause data loss is
crashes at the end of a checkpoint. After the actual checkpoint has been
performed, old WAL files are recycled. When they're filled, their
contents are fdatasynced, but we did not fsync the containing
directory. An OS/hardware crash in an unfortunate moment could then end
up leaving that file with its old name, but new content; WAL replay
would thus not replay it.

Reported-By: Tomas Vondra
Author: Michael Paquier, Tomas Vondra, Andres Freund
Discussion: 56583BDD.9060302@2ndquadrant.com
Backpatch: All supported branches

Introduce durable_rename() and durable_link_or_rename().

Renaming a file using rename(2) is not guaranteed to be durable in face
of crashes; especially on filesystems like xfs and ext4 when mounted
with data=writeback. To be certain that a rename() atomically replaces
the previous file contents in the face of crashes and different
filesystems, one has to fsync the old filename, rename the file, fsync
the new filename, fsync the containing directory.  This sequence is not
generally adhered to currently; which exposes us to data loss risks. To
avoid having to repeat this arduous sequence, introduce
durable_rename(), which wraps all that.

Also add durable_link_or_rename(). Several places use link() (with a
fallback to rename()) to rename a file, trying to avoid replacing the
target file out of paranoia. Some of those rename sequences need to be
durable as well. There seems little reason extend several copies of the
same logic, so centralize the link() callers.

This commit does not yet make use of the new functions; they're used in
a followup commit.

Author: Michael Paquier, Andres Freund
Discussion: 56583BDD.9060302@2ndquadrant.com
Backpatch: All supported branches

Fix incorrect handling of NULL index entries in indexed ROW() comparisons.

An index search using a row comparison such as ROW(a, b) > ROW('x', 'y')
would stop upon reaching a NULL entry in the "b" column, ignoring the
fact that there might be non-NULL "b" values associated with later values
of "a".  This happens because _bt_mark_scankey_required() marks the
subsidiary scankey for "b" as required, which is just wrong: it's for
a column after the one with the first inequality key (namely "a"), and
thus can't be considered a required match.

This bit of brain fade dates back to the very beginnings of our support
for indexed ROW() comparisons, in 2006.  Kind of astonishing that no one
came across it before Glen Takahashi, in bug #14010.

Back-patch to all supported versions.

Note: the given test case doesn't actually fail in unpatched 9.1, evidently
because the fix for bug #6278 (i.e., stopping at nulls in either scan
direction) is required to make it fail.  I'm sure I could devise a case
that fails in 9.1 as well, perhaps with something involving making a cursor
back up; but it doesn't seem worth the trouble.

Send down SYNC message to a failed remote session that was running extended
query protocol.

While running extended query protocol, a backend that has thrown an error will
keep ignoring all messages until it sees a SYNC message. We now carefully track
the messages that we are sending to the remote node and remember if we must
send a SYNC message even before sending a ROLLBACK command.

While the regression was running fine even without this patch, this issue was
noticed as part of some other work and hence fixed

Set log_line_prefix for regression run to collect more information by default

Add test cases to enable/disable certain modules using the new logging
infrastructure

They are not added to either serial or parallel schedules and just serve as
examples right now

Add valgrind suppressions for python code.

Python's allocator does some low-level tricks for efficiency;
unfortunately they trigger valgrind errors. Those tricks can be disabled
making instrumentation easier; but few people testing postgres will have
such a build of python. So add broad suppressions of the resulting
errors.

See also https://svn.python.org/projects/python/trunk/Misc/README.valgrind

This possibly will suppress valid errors, but without it it's basically
impossible to use valgrind with plpython code.

Author: Andres Freund
Backpatch: 9.4, where we started to maintain valgrind suppressions

Add valgrind suppressions for bootstrap related code.

Author: Andres Freund
Backpatch: 9.4, where we started to maintain valgrind suppressions