DEF_PGPORT already comes in from pg_config.h, so we don't need to pass
it in again with a -D option.  Apparently a leftover from the shell
script conversion.

This doesn't actually change the resulting set of strings, but better
be correct.

The --flag argument can be used to tell xgettext the arguments of
which functions should be flagged with c-format in the PO files,
instead of guessing based on the presence of format specifiers, which
fails if no format specifiers are present but the translation
accidentally introduces one.

Appropriate flag settings have been added for each message catalog.

based on a patch by Christoph Berg for bug #6066

Put gettext trigger words that are common to the backend and backend
modules into a makefile variable to include everywhere, to avoid
error-prone repetitions.

Since it's globally defined in c.h, it should be treated as a gettext
trigger everywhere.

It currently doesn't make a difference, but it's inconsistent with
most other usage, and it might interfere with a future patch, so I'll
change it all in a separate commit.

Also, replace tabs with spaces for alignment.

use DBLINK_GET_NAMED_CONN rather than DBLINK_GET_CONN.
Problem found by Peter Eisentraut and patch by Fujii Masao.

Explain that querying pg_locks does not simultaneously lock both the
normal lock manager and the predicate lock manager.

Per discussion with Kevin Grittner.

Backpatch to 9.1 and 9.0.

s/const//g wasn't exactly what I was suggesting here ... parameter
declarations of the form "const structtype *param" are good and useful,
so put those occurrences back.  Likewise, avoid casting away the const
in a "const void *" parameter.

major version.

Backpatch to 9.1.

Dan McGee

This reverts commit addf11f9.
The right fix for the problem is to update the alternative expected
file, not to lobotomize the test case.

binary directory has been validated.

Backpatch to 9.1.

Dan McGee

Backpatch to 9.1 and 9.0.

Dan McGee

Per bug #6073 from Hartmut Raschick.

backend/Makefile was treating errcodes.h as a header always generated
during build, but actually it's a header provided in tarballs.  Hence,
must use the absolute-symlink recipe, not the relative-symlink one.
Per bug #6072 from Hartmut Raschick.

It's not entirely stable.

Per suggestion from Josh Kupershmidt.

As Tom Lane pointed out, "const Relation foo" doesn't guarantee that you
can't modify the data the "foo" pointer points to. It just means that you
can't change the pointer to point to something else within the function,
which is not very useful.

This involves two main changes from the previous behavior.  First,
when we set a bit in the visibility map, emit a new WAL record of type
XLOG_HEAP2_VISIBLE.  Replay sets the page-level PD_ALL_VISIBLE bit and
the visibility map bit.  Second, when inserting, updating, or deleting
a tuple, we can no longer get away with clearing the visibility map
bit after releasing the lock on the corresponding heap page, because
an intervening crash might leave the visibility map bit set and the
page-level bit clear.  Making this work requires a bit of interface
refactoring.

In passing, a few minor but related cleanups: change the test in
visibilitymap_set and visibilitymap_clear to throw an error if the
wrong page (or no page) is pinned, rather than silently doing nothing;
this case should never occur.  Also, remove duplicate definitions of
InvalidXLogRecPtr.

Patch by me, review by Noah Misch.

Josh Kupershmidt

This is just like serial and bigserial, except it generates an int2
column rather than int4 or int8.

Mike Pultz, reviewed by Brar Piening and Josh Kupershmidt

This allows deadlock_timeout to be reduced for transactions that are
particularly likely to be involved in a deadlock, thus detecting it
more quickly.  It is also potentially useful as a poor-man's deadlock
priority mechanism: a transaction with a high deadlock_timeout is less
likely to be chosen as the victim than one with a low
deadlock_timeout.  Since that could be used to game the system, we
make this PGC_SUSET rather than PGC_USERSET.

At some point, it might be worth thinking about a more explicit
priority mechanism, since using this is far from fool-proof.  But
let's see whether there's enough use case to justify the additional
work before we go down that route.

Noah Misch, reviewed by Shigeru Hanada

Initially, we use this only to eliminate calls to the varchar()
function in cases where the length is not being reduced and, therefore,
the function call is equivalent to a RelabelType operation.  The most
significant effect of this is that we can avoid a table rewrite when
changing a varchar(X) column to a varchar(Y) column, where Y > X.

Noah Misch, reviewed by me and Alexey Klyukin

Kevin Grittner, with additional wordsmithing by me.

Fix some grammatical issues, try to clarify a couple of proofs, make the
terminology more consistent.

A password containing a character with the high bit set was misprocessed
on machines where char is signed (which is most).  This could cause the
preceding one to three characters to fail to affect the hashed result,
thus weakening the password.  The result was also unportable, and failed
to match some other blowfish implementations such as OpenBSD's.

Since the fix changes the output for such passwords, upstream chose
to provide a compatibility hack: password salts beginning with $2x$
(instead of the usual $2a$ for blowfish) are intentionally processed
"wrong" to give the same hash as before.  Stored password hashes can
thus be modified if necessary to still match, though it'd be better
to change any affected passwords.

In passing, sync a couple other upstream changes that marginally improve
performance and/or tighten error checking.

Back-patch to all supported branches.  Since this issue is already
public, no reason not to commit the fix ASAP.

used when max_prepared_transactions=0, for the recent changes in the test
case.

already been marked as PREPARED cannot be killed. Kill the current
transaction instead.

One of the prepared_xacts regression tests actually hits this bug. I
removed the anomaly from the duplicate-gids test so that it fails in the
intended way, and added a new test to check serialization failures with
a prepared transaction.

Dan Ports

MARKED_FOR_DEATH flags into one. We still need the ROLLED_BACK flag to
mark transactions that are in the process of being rolled back. To be
precise, ROLLED_BACK now means that a transaction has already been
discounted from the count of transactions with the oldest xmin, but not
yet removed from the list of active transactions.

Dan Ports

Also be more careful about markup: use & not just &.

When recursing after an optimization in pull_up_sublinks_qual_recurse, the
available_rels value passed down must include only the relations that are
in the righthand side of the new SEMI or ANTI join; it's incorrect to pull
up a sub-select that refers to other relations, as seen in the added test
case.  Per report from BangarRaju Vadapalli.

While at it, rethink the idea of recursing below a NOT EXISTS.  That is
essentially the same situation as pulling up ANY/EXISTS sub-selects that
are in the ON clause of an outer join, and it has the same disadvantage:
we'd force the two joins to be evaluated according to the syntactic nesting
order, because the lower join will most likely not be able to commute with
the ANTI join.  That could result in having to form a rather large join
product, whereas the handling of a correlated subselect is not quite that
dumb.  So until we can handle those cases better, #ifdef NOT_USED that
case.  (I think it's okay to pull up in the EXISTS/ANY cases, because SEMI
joins aren't so inflexible about ordering.)

Back-patch to 8.4, same as for previous patch in this area.  Fortunately
that patch hadn't made it into any shipped releases yet.

Some callers were creating copies of tuple descriptors to pass to that
function, stating in code comments that it was necessary because it
modified the passed descriptor.  Code inspection reveals this not to be
true, and indeed not all callers are passing copies in the first place.
So remove the extra ones and the misleading comments about this behavior
as well.