Make the pg_upgrade log files contain actual commands

Now the log file not only contains the output from commands executed by
system(), but also what command it was in the first place.  This
arrangement makes debugging a lot simpler.

Make init-po and update-po recursive make targets

This is for convenience, now that adding recursive targets is much
easier than it used to be when the NLS stuff was initially added.

Fix NOTIFY to cope with I/O problems, such as out-of-disk-space.

The LISTEN/NOTIFY subsystem got confused if SimpleLruZeroPage failed,
which would typically happen as a result of a write() failure while
attempting to dump a dirty pg_notify page out of memory.  Subsequently,
all attempts to send more NOTIFY messages would fail with messages like
"Could not read from file "pg_notify/nnnn" at offset nnnnn: Success".
Only restarting the server would clear this condition.  Per reports from
Kevin Grittner and Christoph Berg.

Back-patch to 9.0, where the problem was introduced during the
LISTEN/NOTIFY rewrite.

pg_upgrade: fix off-by-one mistake in snprintf

snprintf counts trailing NUL towards the char limit.  Failing to account
for that was causing an invalid value to be passed to pg_resetxlog -l,
aborting the upgrade process.

Provide MAP_FAILED if sys/mman.h doesn't.

On old HPUX this has to be #defined to -1.  It might be that other values
are required on other dinosaur systems, but we'll worry about that when
and if we get reports.

Update outdated commit; xlp_rem_len field is in page header now.

Spotted by Amit Kapila

Further fix install program detection

The $(or) make function was introduced in GNU make 3.81, so the
previous coding didn't work in 3.80.  Write it differently, and
improve the variable naming to make more sense in the new coding.

Fix broken mmap failure-detection code, and improve error message.

Per an observation by Thom Brown that my previous commit made an
overly large shmem allocation crash the server, on Linux.

Dramatically reduce System V shared memory consumption.

Except when compiling with EXEC_BACKEND, we'll now allocate only a tiny
amount of System V shared memory (as an interlock to protect the data
directory) and allocate the rest as anonymous shared memory via mmap.
This will hopefully spare most users the hassle of adjusting operating
system parameters before being able to start PostgreSQL with a
reasonable value for shared_buffers.

There are a bunch of documentation updates needed here, and we might
need to adjust some of the HINT messages related to shared memory as
well.  But it's not 100% clear how portable this is, so before we
write the documentation, let's give it a spin on the buildfarm and
see what turns red.

Add missing space in event_source GUC description.

This has apparently been wrong since event_source was added.

Alexander Lakhin

Make UtilityContainsQuery recurse until it finds a non-utility Query.

The callers of UtilityContainsQuery want it to return a non-utility Query
if it returns anything at all.  However, since we made CREATE TABLE
AS/SELECT INTO into a utility command instead of a variant of SELECT,
a command like "EXPLAIN SELECT INTO" results in two nested utility
statements.  So what we need UtilityContainsQuery to do is drill down
to the bottom non-utility Query.

I had thought of this possibility in setrefs.c, and fixed it there by
looping around the UtilityContainsQuery call; but overlooked that the call
sites in plancache.c have a similar issue.  In those cases it's
notationally inconvenient to provide an external loop, so let's redefine
UtilityContainsQuery as recursing down to a non-utility Query instead.

Noted by Rushabh Lathia.  This is a somewhat cleaned-up version of his
proposed patch.

Fix install program detection

configure handles INSTALL as a substitution variable specially, and
apparently it gets confused when it's set to empty.  Use INSTALL_
instead as a workaround to avoid the issue.

Fix two more neglected comments, still referring to log/seg.

Fujii Masao

I neglected many comments in the log+seg -> 64-bit segno patch. Fix.

Reported by Amit Kapila.

Update release notes for pg_terminate_backend changes.

Use system install program when available and usable

In a3176dac22c4cd14971e35119e245abee7649cb9 we switched to using
install-sh unconditionally, because the configure check
AC_PROG_INSTALL would pick up any random program named install, which
has caused failure reports
(http://archives.postgresql.org/pgsql-hackers/2001-03/msg00312.php).
Now the configure check is much improved and should avoid false
positives.  It has also been shown that using a system install program
can significantly reduce "make install" times, so it's worth trying.

Allow pg_terminate_backend() to be used on backends with matching role.

A similar change was made previously for pg_cancel_backend, so now it
all matches again.

Dan Farina, reviewed by Fujii Masao, Noah Misch, and Jeff Davis,
with slight kibitzing on the doc changes by me.

When LWLOCK_STATS is defined, count spindelays.

When LWLOCK_STATS is *not* defined, the only change is that
SpinLockAcquire now returns the number of delays.

Patch by me, review by Jeff Janes.

Cope with smaller-than-normal BLCKSZ setting in SPGiST indexes on text.

The original coding failed miserably for BLCKSZ of 4K or less, as reported
by Josh Kupershmidt.  With the present design for text indexes, a given
inner tuple could have up to 256 labels (requiring either 3K or 4K bytes
depending on MAXALIGN), which means that we can't positively guarantee no
failures for smaller blocksizes.  But we can at least make it behave sanely
so long as there are few enough labels to fit on a page.  Considering that
btree is also more prone to "index tuple too large" failures when BLCKSZ is
small, it's not clear that we should expend more work than this on this
case.

Make DROP FUNCTION hint more informative.

If you decide you want to take the hint, this gives you something you
can paste right back to the server.

Dean Rasheed

Reduce use of heavyweight locking inside hash AM.

Avoid using LockPage(rel, 0, lockmode) to protect against changes to
the bucket mapping.  Instead, an exclusive buffer content lock is now
viewed as sufficient permission to modify the metapage, and a shared
buffer content lock is used when such modifications need to be
prevented.  This more relaxed locking regimen makes it possible that,
when we're busy getting a heavyweight bucket on the bucket we intend
to search or insert into, a bucket split might occur underneath us.
To compenate for that possibility, we use a loop-and-retry system:
release the metapage content lock, acquire the heavyweight lock on the
target bucket, and then reacquire the metapage content lock and check
that the bucket mapping has not changed.   Normally it hasn't, and
we're done.  But if by chance it has, we simply unlock the metapage,
release the heavyweight lock we acquired previously, lock the new
bucket, and loop around again.  Even in the worst case we cannot loop
very many times here, since we don't split the same bucket again until
we've split all the other buckets, and 2^N gets big pretty fast.

This results in greatly improved concurrency, because we're
effectively replacing two lwlock acquire-and-release cycles in
exclusive mode (on one of the lock manager locks) with a single
acquire-and-release cycle in shared mode (on the metapage buffer
content lock).  Testing shows that it's still not quite as good as
btree; for that, we'd probably have to find some way of getting rid
of the heavyweight bucket locks as well, which does not appear
straightforward.

Patch by me, review by Jeff Janes.

Fix pg_upgrade, broken by the xlogid/segno -> 64-bit int refactoring.

The xlogid + segno representation of a particular WAL segment doesn't make
much sense in pg_resetxlog anymore, now that we don't use that anywhere
else. Use the WAL filename instead, since that's a convenient way to name a
particular WAL segment.

I did this partially for pg_resetxlog in the original xlogid/segno -> uint64
patch, but I neglected pg_upgrade and the docs. This should now be more
complete.

Make pg_dump emit more accurate dependency information.

While pg_dump has included dependency information in archive-format output
ever since 7.3, it never made any large effort to ensure that that
information was actually useful.  In particular, in common situations where
dependency chains include objects that aren't separately emitted in the
dump, the dependencies shown for objects that were emitted would reference
the dump IDs of these un-dumped objects, leaving no clue about which other
objects the visible objects indirectly depend on.  So far, parallel
pg_restore has managed to avoid tripping over this misfeature, but only
by dint of some crude hacks like not trusting dependency information in
the pre-data section of the archive.

It seems prudent to do something about this before it rises up to bite us,
so instead of emitting the "raw" dependencies of each dumped object,
recursively search for its actual dependencies among the subset of objects
that are being dumped.

Back-patch to 9.2, since that code hasn't yet diverged materially from
HEAD.  At some point we might need to back-patch further, but right now
there are no known cases where this is actively necessary.  (The one known
case, bug #6699, is fixed in a different way by my previous patch.)  Since
this patch depends on 9.2 changes that made TOC entries be marked before
output commences as to whether they'll be dumped, back-patching further
would require additional surgery; and as of now there's no evidence that
it's worth the risk.

Improve pg_dump's dependency-sorting logic to enforce section dump order.

As of 9.2, with the --section option, it is very important that the concept
of "pre data", "data", and "post data" sections of the output be honored
strictly; else a dump divided into separate sectional files might be
unrestorable.  However, the dependency-sorting logic knew nothing of
sections and would happily select output orderings that didn't fit that
structure.  Doing so was mostly harmless before 9.2, but now we need to be
sure it doesn't do that.  To fix, create dummy objects representing the
section boundaries and add dependencies between them and all the normal
objects.  (This might sound expensive but it seems to only add a percent or
two to pg_dump's runtime.)

This also fixes a problem introduced in 9.1 by the feature that allows
incomplete GROUP BY lists when a primary key is given in GROUP BY.
That means that views can depend on primary key constraints.  Previously,
pg_dump would deal with that by simply emitting the primary key constraint
before the view definition (and hence before the data section of the
output).  That's bad enough for simple serial restores, where creating an
index before the data is loaded works, but is undesirable for speed
reasons.  But it could lead to outright failure of parallel restores, as
seen in bug #6699 from Joe Van Dyk.  That happened because pg_restore would
switch into parallel mode as soon as it reached the constraint, and then
very possibly would try to emit the view definition before the primary key
was committed (as a consequence of another bug that causes the view not to
be correctly marked as depending on the constraint).  Adding the section
boundary constraints forces the dependency-sorting code to break the view
into separate table and rule declarations, allowing the rule, and hence the
primary key constraint it depends on, to revert to their intended location
in the post-data section.  This also somewhat accidentally works around the
bogus-dependency-marking problem, because the rule will be correctly shown
as depending on the constraint, so parallel pg_restore will now do the
right thing.  (We will fix the bogus-dependency problem for real in a
separate patch, but that patch is not easily back-portable to 9.1, so the
fact that this patch is enough to dodge the only known symptom is
fortunate.)

Back-patch to 9.1, except for the hunk that adds verification that the
finished archive TOC list is in correct section order; the place where
it was convenient to add that doesn't exist in 9.1.

Tighten up includes in sinvaladt.h, twophase.h, proc.h

Remove proc.h from sinvaladt.h and twophase.h; also replace xlog.h in
proc.h with xlogdefs.h.

Unify calling conventions for postgres/postmaster sub-main functions

There was a wild mix of calling conventions: Some were declared to
return void and didn't return, some returned an int exit code, some
claimed to return an exit code, which the callers checked, but
actually never returned, and so on.

Now all of these functions are declared to return void and decorated
with attribute noreturn and don't return.  That's easiest, and most
code already worked that way.

Fix typo in DEBUG message, introduced by recent WAL refactoring.

Fujii Masao

Unbreak pg_resetxlog -l.

Fujii Masao

Remove sanity test in XRecOffIsValid.

Commit 061e7efb1b4c5b8a5d02122b7780531b8d5bf23d changed the rules
for splitting xlog records across pages, but neglected to update this
test.  It's possible that there's some better action here than just
removing the test completely, but this at least appears to get some
of the things that are currently broken (like initdb on MacOS X)
working again.

Fix warning for 64-bit literal on 32-bit build.

Replace int2/int4 in C code with int16/int32

The latter was already the dominant use, and it's preferable because
in C the convention is that intXX means XX bits.  Therefore, allowing
mixed use of int2, int4, int8, int16, int32 is obviously confusing.

Remove the typedefs for int2 and int4 for now.  They don't seem to be
widely used outside of the PostgreSQL source tree, and the few uses
can probably be cleaned up by the time this ships.

I missed some references to xlogid/xrecoff in Win32-only code. Fix.

Use UINT64CONST for 64-bit integer constants.

Peter Eisentraut advised me that UINT64CONST is the proper way to do that,
not LL suffix.

Oops. Remove stray paren.

I didn't notice this on my laptop as I don't HAVE_FSYNC_WRITETHROUGH.

Use LL suffix for 64-bit constants.

Per warning from buildfarm member 'locust'. At least I think this what's
making it upset.

Replace XLogRecPtr struct with a 64-bit integer.

This simplifies code that needs to do arithmetic on XLogRecPtrs.

To avoid changing on-disk format of data pages, the LSN on data pages is
still stored in the old format. That should keep pg_upgrade happy. However,
we have XLogRecPtrs embedded in the control file, and in the structs that
are sent over the replication protocol, so this changes breaks compatibility
of pg_basebackup and server. I didn't do anything about this in this patch,
per discussion on -hackers, the right thing to do would to be to change the
replication protocol to be architecture-independent, so that you could use
a newer version of pg_receivexlog, for example, against an older server
version.

Allow WAL record header to be split across pages.

This saves a few bytes of WAL space, but the real motivation is to make it
predictable how much WAL space a record requires, as it no longer depends
on whether we need to waste the last few bytes at end of WAL page because
the header doesn't fit.

The total length field of WAL record, xl_tot_len, is moved to the beginning
of the WAL record header, so that it is still always found on the first page
where a WAL record begins.

Bump WAL version number again as this is an incompatible change.

Move WAL continuation record information to WAL page header.

The continuation record only contained one field, xl_rem_len, so it makes
things simpler to just include it in the WAL page header. This wastes four
bytes on pages that don't begin with a continuation from previos page, plus
four bytes on every page, because of padding.

The motivation of this is to make it easier to calculate how much space a
WAL record needs. Before this patch, it depended on how many page boundaries
the record crosses. The motivation of that, in turn, is to separate the
allocation of space in the WAL from the copying of the record data to the
allocated space. Keeping the calculation of space required simple helps to
keep the critical section of allocating the space from WAL short. But that's
not included in this patch yet.

Bump WAL version number again, as this is an incompatible change.

Don't waste the last segment of each 4GB logical log file.

The comments claimed that wasting the last segment made it easier to do
calculations with XLogRecPtrs, because you don't have problems representing
last-byte-position-plus-1 that way. In my experience, however, it only made
things more complicated, because the there was two ways to represent the
boundary at the beginning of a logical log file: logid = n+1 and xrecoff = 0,
or as xlogid = n and xrecoff = 4GB - XLOG_SEG_SIZE. Some functions were
picky about which representation was used.

Also, use a 64-bit segment number instead of the log/seg combination, to
point to a certain WAL segment. We assume that all platforms have a working
64-bit integer type nowadays.

This is an incompatible change in WAL format, so bumping WAL version number.

Make pgbench -i emit only one-tenth as many status messages.

These days, even a wimpy system can insert 10000 tuples in the blink of
an eye, so there's no real need for this much verbosity.

Per complaint from Tatsuo Ishii.

Document that && can be used to search arrays.

Also, add some cross-links to the indexing documentation, so it's easier
to notice that && and other array operators have index support.

Ryan Kelly, edited by me.

Make placeholders in SQL command help more consistent and precise

To avoid divergent names on related pages, avoid ambiguities, and
reduce translation work a little.

Fix memory leak in ARRAY(SELECT ...) subqueries.

Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which
I think can only happen if the sub-select is embedded in a larger,
correlated subquery) would leak memory for the duration of the query,
due to not reclaiming the array generated in the previous execution.
Per bug #6698 from Armando Miraglia.  Diagnosis and fix idea by Heikki,
patch itself by me.

This has been like this all along, so back-patch to all supported versions.

Repair comment mangled by a pgindent run long ago

Add a small cache of locks owned by a resource owner in ResourceOwner.

This speeds up reassigning locks to the parent owner, when the transaction
holds a lot of locks, but only a few of them belong to the current resource
owner. This is particularly helps pg_dump when dumping a large number of
objects.

The cache can hold up to 15 locks in each resource owner. After that, the
cache is marked as overflowed, and we fall back to the old method of
scanning the whole local lock table. The tradeoff here is that the cache has
to be scanned whenever a lock is released, so if the cache is too large,
lock release becomes more expensive. 15 seems enough to cover pg_dump, and
doesn't have much impact on lock release.

Jeff Janes, reviewed by Amit Kapila and Heikki Linnakangas.

Remove incomplete/incorrect support for zero-column foreign keys.

The original coding in ri_triggers.c had partial support for the concept of
zero-column foreign key constraints.  But this is not defined in the SQL
standard, nor was it ever allowed by any other part of Postgres, nor was it
very fully implemented even here (eg there was no support for preventing
PK-table deletions that would violate the constraint).  Doesn't seem very
useful to carry 100-plus lines of code for a corner case that no one is
interested in making work.  Instead, just add a check that the column list
read from pg_constraint is non-empty.

Increase MAX_SYSCACHE_CALLBACKS from 20 to 32.

By my count there are 18 callers of CacheRegisterSyscacheCallback in the
core code in HEAD, so we are potentially leaving as few as 2 slots for any
add-on code to use (though possibly not all these callers would actually
activate in any particular session).  That doesn't seem like a lot of
headroom, so let's pump it up a little.

Cache the results of ri_FetchConstraintInfo in a backend-local cache.

Extracting data from pg_constraint turned out to take as much as 10% of the
runtime in a bulk-update case where the foreign key column wasn't changing,
because we did it over again for each tuple.  Fix that by maintaining a
backend-local cache of the results.  This is really a pretty small patch,
but converting the trigger functions to work with pointers rather than
local struct variables requires a lot of mechanical changes.

Improve tests for whether we can skip queueing RI enforcement triggers.

During an update of a PK row, we can skip firing the RI trigger if any old
key value is NULL, because then the row could not have had any matching
rows in the FK table.  Conversely, during an update of an FK row, the
outcome is determined if any new key value is NULL.  In either case it
becomes unnecessary to compare individual key values.

This patch was inspired by discussion of Vik Reykja's patch to use IS NOT
DISTINCT semantics for the key comparisons.  In the event there is no need
for that and so this patch looks nothing like his, but he should still get
credit for having re-opened consideration of the trigger skip logic.

Add pgbench option to add foreign key constraints to the standard scenario.

The option --foreign-keys, used at initialization time, will create foreign
key constraints for the columns that represent references to other tables'
primary keys.  This can help in benchmarking FK performance.

Jeff Janes

pg_dump: Fix verbosity level in LO progress messages

In passing, reword another instance of the same message that was
gratuitously different.

Author: Josh Kupershmidt
after a bug report by Bosco Rama

Remove confusing half sentence from legal notice

pointed out by Stefan Kaltenbrunner

Share RI trigger code between NO ACTION and RESTRICT cases.

These triggers are identical except for whether ri_Check_Pk_Match is to be
called, so factor out the common code to save a couple hundred lines.

Also, eliminate null-column checks in ri_Check_Pk_Match, since they're
duplicate with the calling functions and require unnecessary complication
in its API statement.

Simplify the way code is shared between RI_FKey_check_ins and
RI_FKey_check_upd, too.

Improve comments about why SET DEFAULT triggers must recheck for matches.

I was confused about this, so try to make it clearer for the next person.

(This seems like a fairly inefficient way of dealing with a corner case,
but I don't have a better idea offhand.  Maybe if there were a way to turn
off the RI_FKey_keyequal_upd_fk event filter temporarily?)

Allow ON UPDATE/DELETE SET DEFAULT plans to be cached.

Once upon a time, somebody was worried that cached RI plans wouldn't get
remade with new default values after ALTER TABLE ... SET DEFAULT, so they
didn't allow caching of plans for ON UPDATE/DELETE SET DEFAULT actions.
That time is long gone, though (and even at the time I doubt this was the
greatest hazard posed by ALTER TABLE...).  So allow these triggers to cache
their plans just like the others.

The cache_plan argument to ri_PlanCheck is now vestigial, since there
are no callers that don't pass "true"; but I left it alone in case there
is any future need for it.

Remove derived fields from RI_QueryKey, and do a bit of other cleanup.

We really only need the foreign key constraint's OID and the query type
code to uniquely identify each plan we are caching for FK checks.  The
other stuff that was in the struct had no business being used as part of
a hash key, and was all just being copied from struct RI_ConstraintInfo
anyway.  Get rid of the unnecessary fields, and readjust various function
APIs to make them use RI_ConstraintInfo not RI_QueryKey as info source.

I'd be surprised if this makes any measurable performance difference,
but it certainly feels cleaner.

pg_dump: Add missing newlines at end of messages

Update SQL spec references in ri_triggers code to match SQL:2008.

Now that what we're implementing isn't SQL92, we probably shouldn't cite
chapter and verse in that spec anymore.  Also fix some comments that
talked about MATCH FULL but in fact were in code that's also used for
MATCH SIMPLE.

No code changes in this commit, just comments.

Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec.

Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for
a multicolumn MATCH SIMPLE foreign key constraint, we would set only those
referencing columns corresponding to referenced columns that were changed.
This is what the SQL92 standard said to do --- but more recent versions
of the standard say that all referencing columns should be set to null or
their default values, no matter exactly which referenced columns changed.
At least for SET DEFAULT, that is clearly saner behavior.  It's somewhat
debatable whether it's an improvement for SET NULL, but it appears that
other RDBMS systems read the spec this way.  So let's do it like that.

This is a release-notable behavioral change, although considering that
our documentation already implied it was done this way, the lack of
complaints suggests few people use such cases.

Refer to the default foreign key match style as MATCH SIMPLE internally.

Previously we followed the SQL92 wording, "MATCH <unspecified>", but since
SQL99 there's been a less awkward way to refer to the default style.

In addition to the code changes, pg_constraint.confmatchtype now stores
this match style as 's' (SIMPLE) rather than 'u' (UNSPECIFIED).  This
doesn't affect pg_dump or psql because they use pg_get_constraintdef()
to reconstruct foreign key definitions.  But other client-side code might
examine that column directly, so this change will have to be marked as
an incompatibility in the 9.3 release notes.

Make documentation of --help and --version options more consistent

Before, some places didn't document the short options (-? and -V),
some documented both, some documented nothing, and they were listed in
various orders.  Now this is hopefully more consistent and complete.

Fix stats collector to recover nicely when system clock goes backwards.

Formerly, if the system clock went backwards, the stats collector would
fail to update the stats file any more until the clock reading again
exceeds whatever timestamp was last written into the stats file.  Such
glitches in the clock's behavior are not terribly unlikely on machines
not using NTP.  Such a scenario has been observed to cause regression test
failures in the buildfarm, and it could have bad effects on the behavior
of autovacuum, so it seems prudent to install some defenses.

We could directly detect the clock going backwards by adding
GetCurrentTimestamp calls in the stats collector's main loop, but that
would hurt performance on platforms where GetCurrentTimestamp is expensive.
To minimize the performance hit in normal cases, adopt a more complicated
scheme wherein backends check for clock skew when reading the stats file,
and if they see it, signal the stats collector by sending an extra stats
inquiry message.  The stats collector does an extra GetCurrentTimestamp
only when it receives an inquiry with an apparently out-of-order
timestamp.

To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages
to carry the backend's current clock reading as well as its stats cutoff
time.  The latter, being intentionally slightly in-the-past, would trigger
more clock rechecks than we need if it were used for this purpose.

We might want to backpatch this change at some point, but let's let it
shake out in the buildfarm for awhile first.

Reorder basebackup options, to list pg_basebackup first

Since this is the easy way of doing it, it should be listed first. All
the old information is retained for those who want the more advanced way.

Also adds a subheading for compressing logs, that seems to have been missing

Remove 'for' loop perltidy argument, and move args to perltidyrc file.

Backpatch to 9.2.

Per suggestion from Noah Misch

In pgindent, suppress reading the perltidy RC file using --noprofile.

Update pgindent Perl indentation instructions based on feedback from
Àlvaro and Noah Misch.

Backpatch to 9.2.

Improve pg_upgrade wording for pg_ctl start failure;  could be
connection failure.

Backpatch to 9.2.

Per report from Evan D. Hoffman

Improve reporting of permission errors for array types

Because permissions are assigned to element types, not array types,
complaining about permission denied on an array type would be
misleading to users.  So adjust the reporting to refer to the element
type instead.

In order not to duplicate the required logic in two dozen places,
refactor the permission denied reporting for types a bit.

pointed out by Yeb Havinga during the review of the type privilege
feature

Add more message pluralization

Even though we can't do much about the case with multiple plurals in
one sentence, we can fix the other cases.

Improve readability and error messages in pg_backup_start_time.

Gurjeet Singh, with corrections by me.

Doc corrections for pg_is_in_backup patch.

Fujii Masao

New SQL functons pg_backup_in_progress() and pg_backup_start_time()

Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
Marco Nenciarini.  Stylistic cleanup and OID fixes by me.

During transaction cleanup, release locks before deleting files.

There's no need to hold onto the locks until the files are needed,
and by doing it this way, we reduce the impact on other backends who
may be awaiting locks we hold.

Noah Misch

Add new function log_newpage_buffer.

When I implemented the ginbuildempty() function as part of
implementing unlogged tables, I falsified the note in the header
comment for log_newpage.  Although we could fix that up by changing
the comment, it seems cleaner to add a new function which is
specifically intended to handle this case.  So do that.

Remove misplaced sanity check from heap_create().

Even when allow_system_table_mods is not set, we allow creation of any
type of SQL object in pg_catalog, except for relations.  And you can
get relations into pg_catalog, too, by initially creating them in some
other schema and then moving them with ALTER .. SET SCHEMA.  So this
restriction, which prevents relations (only) from being created in
pg_catalog directly, is fairly pointless.  If we need a safety mechanism
for this, it should be placed further upstream, so that it affects all
SQL objects uniformly, and picks up both CREATE and SET SCHEMA.

For now, just rip it out, per discussion with Tom Lane.

Remove RELKIND_UNCATALOGED.

This may have been important at some point in the past, but it no
longer does anything useful.

Review by Tom Lane.

Make \conninfo print SSL information.

Alastair Turner, per suggestion from Bruce Momjian.

Add 9.2 branch to git_changelog's list.

Flesh out RELEASE_CHANGES instructions for branching in git.

We have this info in the wiki, but it should be here too.

Stamp library minor versions for 9.3.

This includes fixing the MSVC copy of ecpg/preproc's version info, which
seems to have been overlooked repeatedly.  Can't we fix that so there are
not two copies??

Stamp HEAD as 9.3devel.

Let the hacking begin ...

Revisit error message details for JSON input parsing.

Instead of identifying error locations only by line number (which could
be entirely unhelpful with long input lines), provide a fragment of the
input text too, placing this info in a new CONTEXT entry.  Make the
error detail messages conform more closely to style guidelines, fix
failure to expose some of them for translation, ensure compiler can
check formats against supplied parameters.

Remove release note entry for reverted patch.

Revert "Reduce checkpoints and WAL traffic on low activity database server"

This reverts commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724.  Per
discussion, it does not seem like a good idea to allow committed changes to
go un-checkpointed indefinitely, as could happen in a low-traffic server;
that makes us entirely reliant on the WAL stream with no redundancy that
might aid data recovery in case of disk failure.

This re-introduces the original problem of hot-standby setups generating a
small continuing stream of WAL traffic even when idle, but there are other
ways to address that without compromising crash recovery, so we'll revisit
that issue in a future release cycle.

Fix description of SQL-standard meaning of CREATE LOCAL TEMP TABLE.

I had this slightly wrong, as noted by Noah Misch.

Deprecate use of GLOBAL and LOCAL in temp table creation.

Aside from adjusting the documentation to say that these are deprecated,
we now report a warning (not an error) for use of GLOBAL, since it seems
fairly likely that we might change that to request SQL-spec-compliant temp
table behavior in the foreseeable future.  Although our handling of LOCAL
is equally nonstandard, there is no evident interest in ever implementing
SQL modules, and furthermore some other products interpret LOCAL as
behaving the same way we do.  So no expectation of change and no warning
for LOCAL; but it still seems a good idea to deprecate writing it.

Noah Misch

Support Linux's oom_score_adj API as well as the older oom_adj API.

The simplest way to handle this is just to copy-and-paste the relevant
code block in fork_process.c, so that's what I did. (It's possible that
something more complicated would be useful to packagers who want to work
with either the old or the new API; but at this point the number of such
people is rapidly approaching zero, so let's just get the minimal thing
done.)  Update relevant documentation as well.

In pg_upgrade, verify that the install user has the same oid on both
clusters, and make sure the new cluster has no additional users.

Backpatch to 9.1.

Improve documentation of postgres -C option

Clarify help (s/return/print/), and explain that this option is for
use by other programs, not for user-facing use (it does not print
units).

Minor code review for json.c.

Improve commenting, conform to project style for use of ++ etc.
No functional changes.

Mark JSON error detail messages for translation.

Per gripe from Tom Lane.

Copy-editing of release notes.

Remove a couple of items that were actually back-patched bug fixes.
Add additional details to a couple of items which lacked a description.
Improve attributions for a couple of items I was involved with.
A few other miscellaneous corrections.

Ensure pg_ctl behaves sanely when data directory is not specified.

Commit aaa6e1def292cdacb6b27088898793b1b879fedf introduced multiple hazards
in the case where pg_ctl is executed with neither a -D switch nor any
PGDATA environment variable.  It would dump core on machines which are
unforgiving about printf("%s", NULL), or failing that possibly give a
rather unhelpful complaint about being unable to execute "postgres -C",
rather than the logically prior complaint about not being told where the
data directory is.

Edmund Horner's report suggests that there is another, Windows-specific
hazard here, but I'm not the person to fix that; it would in any case only
be significant when trying to use a config-only PGDATA pointer.

Fix pg_dump output to a named tar-file archive.

"pg_dump -Ft -f filename ..." got broken by my recent commit
4317e0246c645f60c39e6572644cff1cb03b4c65, which I fear I only tested
in the output-to-stdout variant.

Report and fix by Muhammad Asif Naeem.

pg_receivexlog: Rename option --dir to --directory

getopt_long() allows abbreviating long options, so we might as well
give the option the full name, and users can abbreviate it how they
like.

Do some general polishing of the --help output at the same time.

Prevent non-streaming replication connections from being selected sync slave

This prevents a pg_basebackup backup session that just does a base
backup (no xlog involved at all) from becoming the synchronous slave
and thus blocking all access while it runs.

Also fixes the problem when a higher priority slave shows up it would
become the sync standby before it has reached the STREAMING state, by
making sure we can only switch to a walsender that's actually STREAMING.

Fujii Masao

Revert behaviour of -x/--xlog to 9.1 semantics

To replace it, add -X/--xlog-method that allows the specification
of fetch or stream.

Do this to avoid unnecessary backwards-incompatiblity. Spotted and
suggested by Peter Eisentraut.

Run pgindent on 9.2 source tree in preparation for first 9.3
commit-fest.

Update pgindent install instructions and update typedef list.

Fix pg_basebackup/pg_receivexlog for floating point timestamps

Since the replication protocol deals with TimestampTz, we need to
care for the floating point case as well in the frontend tools.

Fujii Masao, with changes from Magnus Hagander