bdr: mergme: Only add truncate trigger if CREATE TABLE

bdr: avoid race conditions when installing bdr extensions

Previously installing the bdr (and prerequisite) extensions was racy
because only the sequencer installed them. Initially that wasn't much
of a problem since only the sequencer and manual queries needed the
schema, but that's not true anymore.

Instead check whether the schema exists in every started worker and
prevent races by acquiring a suitably strong lock on pg_extension
while checking/creating.

bdr: enabling CREATE TRIGGER replication

bdr: implement support for TRUNCATE TABLE replication

bdr: Don't insert commands into bdr_queued_commands during replay.

bdr: formatting fixes for bdr--0.5.sql

bdr: moved GUCs to one-dot notation

bdr: ignore temp objects when queueing

bdr: Initial DDL replication

This simply accumulates DDL commands in a table, and has the bdr_apply
background worker execute it.

bdr: Initialize bgw_notify_pid to 0

Failure to do this resulted in a bgworker that would not run in some
cases.

bdr: fix nasty typo leading to pkey extraction using the wrong type

bdr: pgbench: delete instead of truncate

bdr: bdr plugin

Andres Freund, Alvaro Herrera, Abhijit Menon-Sen

bdr,core: Add database oid to IDENTIFY_SYSTEM

Adjust all IDENTIFY_SYSTEM callers

bdr,core: isolationtester: Isolationtester with multi-server support

The spec file can now start with declarations like this:

    conninfo "cname1" "port=NNNN dbname=XYZ"
    conninfo "cname2" "port=MMMM dbname=PQR"

And sessions may include connection declarations like this:

    session "s1"
    connection "cname1"

Both are optional. If no connection information is explicitly specified,
then the earlier behaviour (use conninfo from commandline or fall back
to "dbname=postgres") is retained.

If connection information is specified, we open one "global" connection
per conninfo (for lock checking) and one connection per session. Setup
SQL is executed only on conns[0], as before (but perhaps it would help
to execute it on all until DDL replication is implemented?).

Includes the rudimentary tests from before, including some failing ones.

wal_decoding: Add pg_xlog_wait_remote_{apply,receive} functions

We want to use these in isolationtester tests, but they're more
generally useful for "inter-node synchronisation".

core, bdr: Add --snapshot argument to pg_dump, allowing user-specified snapshot to dump

Allows pg_dump to dump from a snapshot that already exists. pg_dump already
supported SET TRANSACTION SNAPSHOT for use in parallel dump, but didn't allow
the user to explicitly specify the snapshot.

This is useful in BDR/UDR, where we want to initialize a new replica
using the state of an existing node from the snapshot automatically
exported by a slot.

Author: Simon Riggs

wal_decoding: Add (non-)transactional message feature for logical decoding

core: Hack around function_parse_error_transpose() hack of using portal's query text

core: Add strtoll/strtoull emulation if necessary.

seqam: v0.2.3

replication_identifiers: v0.3.2

Introduce feature to keep track of replication progress.

Replication identifiers can be used to track & lookup remote nodes identified
via (sysid, tlid, remote_dbid, local_dbid, name) and map that tuple to a local
uint16.

Keyed by that replication identifier the progress of replication from
that system is tracked in a crashsafe manner.

Support for tracking that via output plugins is added as well.

Needs a catversion bump.

committs: v0.4.5

Alvaro Herrera, from 20131022221600.GE4987@eldon.alvh.no-ip.org

core: use PG_FUNCNAME_MACRO to avoid stale name

event_trigger.c: Fix typo in comment

gram.y: more psprintf()

json.c: fix typo

Merge remote-tracking branch '2ndq-bdr/deparse_9_4' into HEAD

* 2ndq-bdr/deparse_9_4: (34 commits)
  deparse: support GRANT/REVOKE
  deparse: Support ALTER EXTENSION / UPDATE TO
  deparse: support ALTER THING OWNER TO
  deparse: Support CREATE AGGREGATE
  deparse: Initial support for CREATE TEXT SEARCH CONFIGURATION
  deparse: Support CREATE TYPE via DefineStmt
  deparse: Support CREATE TEXT SEARCH DICTIONARY via DefineStmt
  deparse: Support CREATE TEXT SEARCH PARSER via DefineStmt
  deparse: Support CREATE TEXT SEARCH TEMPLATE via DefineStmt
  deparse: Support CREATE COLLATION via DefineStmt
  deparse: Support CREATE OPERATOR via DefineStmt
  deparse: Support CREATE CONVERSION
  deparse: Support CREATE OPERATOR FAMILY
  deparse: initial support for ALTER TABLE
  deparse: deparse CREATE FUNCTION
  deparse/core: enable deparse of function defaults expr
  deparse: support CREATE DOMAIN
  deparse: add support for ALTER THING RENAME
  deparse: support ALTER TYPE / ADD VALUE (for enums)
  deparse: add support for CREATE RULE
  ...

Merge remote-tracking branch '2ndq-bdr/bdr-drops_9_4' into HEAD

* 2ndq-bdr/bdr-drops_9_4:
  bdr-drops: add some docs
  bdr-drops: emit empty objnames for amproc/amop objs
  bdr-drops: Set "normal" flag when DEPFLAG_REVERSE
  bdr-drops: allow extracting objname/args from address
  core: fix bizarre skipping logic

Use a separate temporary directory for the Unix-domain socket

Creating the Unix-domain socket in the build directory can run into
name-length limitations.  Therefore, create the socket file in the
default temporary directory of the operating system.  Keep the temporary
data directory etc. in the build tree.

Support vpath builds in TAP tests

Smooth reporting of commit/rollback statistics.

If a connection committed or rolled back any transactions within a
PGSTAT_STAT_INTERVAL pacing interval without accessing any tables,
the reporting of those statistics would be held up until the
connection closed or until it ended a PGSTAT_STAT_INTERVAL interval
in which it had accessed a table.  This could result in under-
reporting of transactions for an extended period, followed by a
spike in reported transactions.

While this is arguably a bug, the impact is minimal, primarily
affecting, and being affected by, monitoring software.  It might
cause more confusion than benefit to change the existing behavior
in released stable branches, so apply only to master and the 9.4
beta.

Gurjeet Singh, with review and editing by Kevin Grittner,
incorporating suggested changes from Abhijit Menon-Sen and Tom
Lane.

pg_upgrade:  preserve database and relation minmxid values

Also set these values for pre-9.3 old clusters that don't have values to
preserve.

Analysis by Alvaro

Backpatch through 9.3

pg_upgrade:  no need to remove "members" files for pre-9.3 upgrades

Per analysis by Alvaro

Backpatch through 9.3

Add some errdetail to checkRuleResultList().

This function wasn't originally thought to be really user-facing,
because converting a table to a view isn't something we expect people
to do manually.  So not all that much effort was spent on the error
messages; in particular, while the code will complain that you got
the column types wrong it won't say exactly what they are.  But since
we repurposed the code to also check compatibility of rule RETURNING
lists, it's definitely user-facing.  It now seems worthwhile to add
errdetail messages showing exactly what the conflict is when there's
a mismatch of column names or types.  This is prompted by bug #10836
from Matthias Raffelsieper, which might have been forestalled if the
error message had reported the wrong column type as being "record".

Back-patch to 9.4, but not into older branches where the set of
translatable error strings is supposed to be stable.

Prevent psql from issuing BEGIN before ALTER SYSTEM when AUTOCOMMIT is off.

The autocommit-off mode works by issuing an implicit BEGIN just before
any command that is not already in a transaction block and is not itself
a BEGIN or other transaction-control command, nor a command that
cannot be executed inside a transaction block. This commit prevents psql
from issuing such an implicit BEGIN before ALTER SYSTEM because it's
not allowed inside a transaction block.

Backpatch to 9.4 where ALTER SYSTEM was added.

Report by Feike Steenbergen

Fix inadequately-sized output buffer in contrib/unaccent.

The output buffer size in unaccent_lexize() was calculated as input string
length times pg_database_encoding_max_length(), which effectively assumes
that replacement strings aren't more than one character.  While that was
all that we previously documented it to support, the code actually has
always allowed replacement strings of arbitrary length; so if you tried
to make use of longer strings, you were at risk of buffer overrun.  To fix,
use an expansible StringInfo buffer instead of trying to determine the
maximum space needed a-priori.

This would be a security issue if unaccent rules files could be installed
by unprivileged users; but fortunately they can't, so in the back branches
the problem can be labeled as improper configuration by a superuser.
Nonetheless, a memory stomp isn't a nice way of reacting to improper
configuration, so let's back-patch the fix.

pg_upgrade:  update C comments about pg_dumpall

There were some C comments that hadn't been updated from the switch of
using only pg_dumpall to using pg_dump and pg_dumpall, so update them.
Also, don't bother using --schema-only for pg_dumpall --globals-only.

Backpatch through 9.4

Don't prematurely free the BufferAccessStrategy in pgstat_heap().

This function continued to use it after heap_endscan() freed it.  In
passing, don't explicit create a strategy here.  Instead, use the one
created by heap_beginscan_strat(), if any.  Back-patch to 9.2, where use
of a BufferAccessStrategy here was introduced.

Check interrupts during logical decoding more frequently.

When reading large amounts of preexisting WAL during logical decoding
using the SQL interface we possibly could fail to check interrupts in
due time. Similarly the same could happen on systems with a very high
WAL volume while creating a new logical replication slot, independent
of the used interface.

Previously these checks where only performed in xlogreader's read_page
callbacks, while waiting for new WAL to be produced. That's not
sufficient though, if there's never a need to wait.  Walsender's send
loop already contains a interrupt check.

Backpatch to 9.4 where the logical decoding feature was introduced.

Revert the assertion of no palloc's in critical section.

Per discussion, it still fires too often to be safe to enable in
production. Keep it in master, so that we find the issues, but disable it
in the stable branch.

Remove use_json_as_text options from json_to_record/json_populate_record.

The "false" case was really quite useless since all it did was to throw
an error; a definition not helped in the least by making it the default.
Instead let's just have the "true" case, which emits nested objects and
arrays in JSON syntax.  We might later want to provide the ability to
emit sub-objects in Postgres record or array syntax, but we'd be best off
to drive that off a check of the target field datatype, not a separate
argument.

For the functions newly added in 9.4, we can just remove the flag arguments
outright.  We can't do that for json_populate_record[set], which already
existed in 9.3, but we can ignore the argument and always behave as if it
were "true".  It helps that the flag arguments were optional and not
documented in any useful fashion anyway.

Have multixact be truncated by checkpoint, not vacuum

Instead of truncating pg_multixact at vacuum time, do it only at
checkpoint time.  The reason for doing it this way is twofold: first, we
want it to delete only segments that we're certain will not be required
if there's a crash immediately after the removal; and second, we want to
do it relatively often so that older files are not left behind if
there's an untimely crash.

Per my proposal in
http://www.postgresql.org/message-id/20140626044519.GJ7340@eldon.alvh.no-ip.org
we now execute the truncation in the checkpointer process rather than as
part of vacuum.  Vacuum is in only charge of maintaining in shared
memory the value to which it's possible to truncate the files; that
value is stored as part of checkpoints also, and so upon recovery we can
reuse the same value to re-execute truncate and reset the
oldest-value-still-safe-to-use to one known to remain after truncation.

Per bug reported by Jeff Janes in the course of his tests involving
bug #8673.

While at it, update some comments that hadn't been updated since
multixacts were changed.

Backpatch to 9.3, where persistency of pg_multixact files was
introduced by commit 0ac5ad5134f2.

Don't allow relminmxid to go backwards during VACUUM FULL

We were allowing a table's pg_class.relminmxid value to move backwards
when heaps were swapped by VACUUM FULL or CLUSTER.  There is a
similar protection against relfrozenxid going backwards, which we
neglected to clone when the multixact stuff was rejiggered by commit
0ac5ad5134f276.

Backpatch to 9.3, where relminmxid was introduced.

As reported by Heikki in
http://www.postgresql.org/message-id/52401AEA.9000608@vmware.com

Fix broken Assert() introduced by 8e9a16ab8f7f0e58

Don't assert MultiXactIdIsRunning if the multi came from a tuple that
had been share-locked and later copied over to the new cluster by
pg_upgrade.  Doing that causes an error to be raised unnecessarily:
MultiXactIdIsRunning is not open to the possibility that its argument
came from a pg_upgraded tuple, and all its other callers are already
checking; but such multis cannot, obviously, have transactions still
running, so the assert is pointless.

Noticed while investigating the bogus pg_multixact/offsets/0000 file
left over by pg_upgrade, as reported by Andres Freund in
http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de

Backpatch to 9.3, as the commit that introduced the buglet.

Disallow pushing volatile qual expressions down into DISTINCT subqueries.

A WHERE clause applied to the output of a subquery with DISTINCT should
theoretically be applied only once per distinct row; but if we push it
into the subquery then it will be evaluated at each row before duplicate
elimination occurs.  If the qual is volatile this can give rise to
observably wrong results, so don't do that.

While at it, refactor a little bit to allow subquery_is_pushdown_safe
to report more than one kind of restrictive condition without indefinitely
expanding its argument list.

Although this is a bug fix, it seems unwise to back-patch it into released
branches, since it might de-optimize plans for queries that aren't giving
any trouble in practice.  So apply to 9.4 but not further back.

Get rid of bogus separate pg_proc entries for json_extract_path operators.

These should not have existed to begin with, but there was apparently some
misunderstanding of the purpose of the opr_sanity regression test item
that checks for operator implementation functions with their own comments.
The idea there is to check for unintentional violations of the rule that
operator implementation functions shouldn't be documented separately
.... but for these functions, that is in fact what we want, since the
variadic option is useful and not accessible via the operator syntax.
Get rid of the extra pg_proc entries and fix the regression test and
documentation to be explicit about what we're doing here.

Forward-patch regression test for "could not find pathkey item to sort".

Commit a87c729153e372f3731689a7be007bc2b53f1410 already fixed the bug this
is checking for, but the regression test case it added didn't cover this
scenario.  Since we managed to miss the fact that there was a bug at all,
it seems like a good idea to propagate the extra test case forward to HEAD.

Remove obsolete example of CSV log file name from log_filename document.

7380b63 changed log_filename so that epoch was not appended to it
when no format specifier is given. But the example of CSV log file name
with epoch still left in log_filename document. This commit removes
such obsolete example.

This commit also documents the defaults of log_directory and
log_filename.

Backpatch to all supported versions.

Christoph Berg

Rationalize error messages within jsonfuncs.c.

I noticed that the functions in jsonfuncs.c sometimes printed error
messages that claimed I'd called some other function.  Investigation showed
that this was from repurposing code into "worker" functions without taking
much care as to whether it would mention the right SQL-level function if it
threw an error.  Moreover, there was a weird mismash of messages that
contained a fixed function name, messages that used %s for a function name,
and messages that constructed a function name out of spare parts, like
"json%s_populate_record" (which, quite aside from being ugly as sin, wasn't
even sufficient to cover all the cases).  This would put an undue burden on
our long-suffering translators.  Standardize on inserting the SQL function
name with %s so as to reduce the number of translatable strings, and pass
function names around as needed to make sure we can report the right one.
Fix up some gratuitous variations in wording, too.

Cosmetic improvements in jsonfuncs.c.

Re-pgindent, remove a lot of random vertical whitespace, remove useless
(if not counterproductive) inline markings, get rid of unnecessary
zero-padding of strings for hashtable searches.  No functional changes.

Fix handling of nested JSON objects in json_populate_recordset and friends.

populate_recordset_object_start() improperly created a new hash table
(overwriting the link to the existing one) if called at nest levels
greater than one.  This resulted in previous fields not appearing in
the final output, as reported by Matti Hameister in bug #10728.
In 9.4 the problem also affects json_to_recordset.

This perhaps missed detection earlier because the default behavior is to
throw an error for nested objects: you have to pass use_json_as_text = true
to see the problem.

In addition, fix query-lifespan leakage of the hashtable created by
json_populate_record().  This is pretty much the same problem recently
fixed in dblink: creating an intended-to-be-temporary context underneath
the executor's per-tuple context isn't enough to make it go away at the
end of the tuple cycle, because MemoryContextReset is not
MemoryContextResetAndDeleteChildren.

Michael Paquier and Tom Lane

pg_upgrade:  remove pg_multixact files left by initdb

This fixes a bug that caused vacuum to fail when the '0000' files left
by initdb were accessed as part of vacuum's cleanup of old pg_multixact
files.

Backpatch through 9.3

Don't allow foreign tables with OIDs.

The syntax doesn't let you specify "WITH OIDS" for foreign tables, but it
was still possible with default_with_oids=true. But the rest of the system,
including pg_dump, isn't prepared to handle foreign tables with OIDs
properly.

Backpatch down to 9.1, where foreign tables were introduced. It's possible
that there are databases out there that already have foreign tables with
OIDs. There isn't much we can do about that, but at least we can prevent
them from being created in the future.

Patch by Etsuro Fujita, reviewed by Hadi Moshayedi.

Fix typo in replication slot function doc.

Add missing closing parenthesis into max_replication_slots doc.

doc:  adjust JSONB GIN index description

Backpatch through 9.4

9.4 release notes:  adjust some entry wording

Backpatch to 9.4

Fix documentation template for CREATE TRIGGER.

By using curly braces, the template had specified that one of
"NOT DEFERRABLE", "INITIALLY IMMEDIATE", or "INITIALLY DEFERRED"
was required on any CREATE TRIGGER statement, which is not
accurate.  Change to square brackets makes that optional.

Backpatch to 9.1, where the error was introduced.

Clean up data conversion short-lived memory context.

dblink uses a short-lived data conversion memory context. However it
was not deleted when no longer needed, leading to a noticeable memory
leak under some circumstances. Plug the hole, along with minor
refactoring. Backpatch to 9.2 where the leak was introduced.

Report and initial patch by MauMau. Reviewed/modified slightly by
Tom Lane and me.

Do all-visible handling in lazy_vacuum_page() outside its critical section.

Since fdf9e21196a lazy_vacuum_page() rechecks the all-visible status
of pages in the second pass over the heap. It does so inside a
critical section, but both visibilitymap_test() and
heap_page_is_all_visible() perform operations that should not happen
inside one. The former potentially performs IO and both potentially do
memory allocations.

To fix, simply move all the all-visible handling outside the critical
section. Doing so means that the PD_ALL_VISIBLE on the page won't be
included in the full page image of the HEAP2_CLEAN record anymore. But
that's fine, the flag will be set by the HEAP2_VISIBLE logged later.

Backpatch to 9.3 where the problem was introduced. The bug only came
to light due to the assertion added in 4a170ee9 and isn't likely to
cause problems in production scenarios. The worst outcome is a
avoidable PANIC restart.

This also gets rid of the difference in the order of operations
between master and standby mentioned in 2a8e1ac5.

Per reports from David Leverton and Keith Fiske in bug #10533.

Avoid leaking memory while evaluating arguments for a table function.

ExecMakeTableFunctionResult evaluated the arguments for a function-in-FROM
in the query-lifespan memory context.  This is insignificant in simple
cases where the function relation is scanned only once; but if the function
is in a sub-SELECT or is on the inside of a nested loop, any memory
consumed during argument evaluation can add up quickly.  (The potential for
trouble here had been foreseen long ago, per existing comments; but we'd
not previously seen a complaint from the field about it.)  To fix, create
an additional temporary context just for this purpose.

Per an example from MauMau.  Back-patch to all active branches.

Document SQL functions' behavior of parsing the whole function at once.

Haribabu Kommi, somewhat rewritten by me

Fix calculation of PREDICATELOCK_MANAGER_LWLOCK_OFFSET.

Commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f failed to include
NUM_BUFFER_PARTITIONS in this offset, resulting in a bad offset.
Ultimately this threw off NUM_FIXED_LWLOCKS which is based on
earlier offsets, leading to memory allocation problems.  It seems
likely to have also caused increased LWLOCK contention when
serializable transactions were used, because lightweight locks used
for that overlapped others.

Reported by Amit Kapila with analysis and fix.
Backpatch to 9.4, where the bug was introduced.

Don't allow data_directory to be set in postgresql.auto.conf by ALTER SYSTEM.

data_directory could be set both in postgresql.conf and postgresql.auto.conf so far.
This could cause some problematic situations like circular definition. To avoid such
situations, this commit forbids a user to set data_directory in postgresql.auto.conf.

Backpatch this to 9.4 where ALTER SYSTEM command was introduced.

Amit Kapila, reviewed by Abhijit Menon-Sen, with minor adjustments by me.

Remove unnecessary check for jbvBinary in convertJsonbValue.

The check was confusing and is a condition that should never in fact
happen.

Per gripe from Dmitry Dolgov.

Fix weird spacing in error message.

Seems to have been introduced in 1a3458b6d8d202715a83c88474a1b63726d0929e.

Document that jsonb has all the standard comparison operators.

bdr-drops: add some docs

bdr-drops: emit empty objnames for amproc/amop objs

We return empty identifying lists, which might not be the prettiest
thing in the world, rather than failing an Assert().  get_object_address
doesn't accept such objects anyway, so pretending to return something
useful would be a waste of time (and would probably require checks
elsewhere to avoid passing such addresses to get_object_address).

bdr-drops: Set "normal" flag when DEPFLAG_REVERSE

This seems to fix the problem for views depending on tables without
causing problems elsewhere.

Whether this approach is really correct remains to be seen.  Do we need
a separate flag in pg_event_trigger_get_dropped_objects() to return the
"reverse internal" status?  Seems awkward, so for now just turn it into
a "normal" dependency instead.

bdr-drops: allow extracting objname/args from address

core: fix bizarre skipping logic

deparse: support GRANT/REVOKE

deparse: Support ALTER EXTENSION / UPDATE TO

deparse: support ALTER THING OWNER TO

deparse: Support CREATE AGGREGATE

deparse: Initial support for CREATE TEXT SEARCH CONFIGURATION

Since there's no way to create token-dict mappings with this CREATE
command, we search for them and refuse to deparse the configuration
if they exist.

deparse: Support CREATE TYPE via DefineStmt

deparse: Support CREATE TEXT SEARCH DICTIONARY via DefineStmt

deparse: Support CREATE TEXT SEARCH PARSER via DefineStmt

deparse: Support CREATE TEXT SEARCH TEMPLATE via DefineStmt

deparse: Support CREATE COLLATION via DefineStmt

deparse: Support CREATE OPERATOR via DefineStmt

deparse: Support CREATE CONVERSION

deparse: Support CREATE OPERATOR FAMILY

deparse: initial support for ALTER TABLE

deparse: deparse CREATE FUNCTION

deparse/core: enable deparse of function defaults expr

deparse: support CREATE DOMAIN

deparse: add support for ALTER THING RENAME

It supports everything but functions, aggregates, operator classes and
operator families.

deparse: support ALTER TYPE / ADD VALUE (for enums)

deparse: add support for CREATE RULE

deparse: Add support for CREATE EXTENSION

deparse: support CREATE TYPE AS RANGE

deparse: Initial support for JSON command deparsing

deparse/core: PGDLLIMPORT creating_extension

deparse/core: add get_sequence_values()

deparse/core: add format_type_detailed()

deparse/core: event triggers support GRANT/REVOKE