Fix CLUSTER/VACUUM FULL for toast values owned by recently-updated rows.

In commit 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05, I made CLUSTER and
VACUUM FULL try to preserve toast value OIDs from the original toast table
to the new one.  However, if we have to copy both live and recently-dead
versions of a row that has a toasted column, those versions may well
reference the same toast value with the same OID.  The patch then led to
duplicate-key failures as we tried to insert the toast value twice with the
same OID.  (The previous behavior was not very desirable either, since it
would have silently inserted the same value twice with different OIDs.
That wastes space, but what's worse is that the toast values inserted for
already-dead heap rows would not be reclaimed by subsequent ordinary
VACUUMs, since they go into the new toast table marked live not deleted.)

To fix, check if the copied OID already exists in the new toast table, and
if so, assume that it stores the desired value.  This is reasonably safe
since the only case where we will copy an OID from a previous toast pointer
is when toast_insert_or_update was given that toast pointer and so we just
pulled the data from the old table; if we got two different values that way
then we have big problems anyway.  We do have to assume that no other
backend is inserting items into the new toast table concurrently, but
that's surely safe for CLUSTER and VACUUM FULL.

Per bug #6393 from Maxim Boguk.  Back-patch to 9.0, same as the previous
patch.

Fix one-byte buffer overrun in contrib/test_parser.

The original coding examined the next character before verifying that
there *is* a next character.  In the worst case with the input buffer
right up against the end of memory, this would result in a segfault.

Problem spotted by Paul Guyot; this commit extends his patch to fix an
additional case.  In addition, make the code a tad more readable by not
overloading the usage of *tlen.

Use __sync_lock_test_and_set() for spinlocks on ARM, if available.

Historically we've used the SWPB instruction for TAS() on ARM, but this
is deprecated and not available on ARMv6 and later.  Instead, make use
of a GCC builtin if available.  We'll still fall back to SWPB if not,
so as not to break existing ports using older GCC versions.

Eventually we might want to try using __sync_lock_test_and_set() on some
other architectures too, but for now that seems to present only risk and
not reward.

Back-patch to all supported versions, since people might want to use any
of them on more recent ARM chips.

Martin Pitt

Fix pg_restore's direct-to-database mode for INSERT-style table data.

In commit 6545a901aaf84cb05212bb6a7674059908f527c3, I removed the mini SQL
lexer that was in pg_backup_db.c, thinking that it had no real purpose
beyond separating COPY data from SQL commands, which purpose had been
obsoleted by long-ago fixes in pg_dump's archive file format.
Unfortunately this was in error: that code was also used to identify
command boundaries in INSERT-style table data, which is run together as a
single string in the archive file for better compressibility.  As a result,
direct-to-database restores from archive files made with --inserts or
--column-inserts fail in our latest releases, as reported by Dick Visser.

To fix, restore the mini SQL lexer, but simplify it by adjusting the
calling logic so that it's only required to cope with INSERT-style table
data, not arbitrary SQL commands.  This allows us to not have to deal with
SQL comments, E'' strings, or dollar-quoted strings, none of which have
ever been emitted by dumpTableData_insert.

Also, fix the lexer to cope with standard-conforming strings, which was the
actual bug that the previous patch was meant to solve.

Back-patch to all supported branches.  The previous patch went back to 8.2,
which unfortunately means that the EOL release of 8.2 contains this bug,
but I don't think we're doing another 8.2 release just because of that.

Make executor's SELECT INTO code save and restore original tuple receiver.

As previously coded, the QueryDesc's dest pointer was left dangling
(pointing at an already-freed receiver object) after ExecutorEnd.  It's a
bit astonishing that it took us this long to notice, and I'm not sure that
the known problem case with SQL functions is the only one.  Fix it by
saving and restoring the original receiver pointer, which seems the most
bulletproof way of ensuring any related bugs are also covered.

Per bug #6379 from Paul Ramsey.  Back-patch to 8.4 where the current
handling of SELECT INTO was introduced.

Update per-column ACLs, not only per-table ACL, when changing table owner.

We forgot to modify column ACLs, so privileges were still shown as having
been granted by the old owner.  This meant that neither the new owner nor
a superuser could revoke the now-untraceable-to-table-owner permissions.
Per bug #6350 from Marc Balmer.

This has been wrong since column ACLs were added, so back-patch to 8.4.

Avoid crashing when we have problems unlinking files post-commit.

smgrdounlink takes care to not throw an ERROR if it fails to unlink
something, but that caution was rendered useless by commit
3396000684b41e7e9467d1abc67152b39e697035, which put an smgrexists call in
front of it; smgrexists *does* throw error if anything looks funny, such
as getting a permissions error from trying to open the file.  If that
happens post-commit, you get a PANIC, and what's worse the same logic
appears in the WAL replay code, so the database even fails to restart.

Restore the intended behavior by removing the smgrexists call --- it isn't
accomplishing anything that we can't do better by adjusting mdunlink's
ideas of whether it ought to warn about ENOENT or not.

Per report from Joseph Shraibman of unrecoverable crash after trying to
drop a table whose FSM fork had somehow gotten chmod'd to 000 permissions.
Backpatch to 8.4, where the bogus coding was introduced.

In ecpg removed old leftover check for given connection name.

Ever since we introduced real prepared statements this should work for
different connections. The old solution just emulating prepared statements,
though, wasn't able to handle this.

Closes: #6309

Fix reference to "verify-ca" and "verify-full" in a note in the docs.

Disable excessive FP optimization by recent versions of gcc.

Suggested solution from Tom Lane. Problem discovered, probably not
for the first time, while testing the mingw-w64 32 bit compiler.

Backpatched to all live branches.

Revert the behavior of inet/cidr functions to not unpack the arguments.

I forgot to change the functions to use the PG_GETARG_INET_PP() macro,
when I changed DatumGetInetP() to unpack the datum, like Datum*P macros
usually do. Also, I screwed up the definition of the PG_GETARG_INET_PP()
macro, and didn't notice because it wasn't used.

This fixes the memory leak when sorting inet values, as reported
by Jochen Erwied and debugged by Andres Freund. Backpatch to 8.3, like
the previous patch that broke it.

Don't set reachedMinRecoveryPoint during crash recovery. In crash recovery,
we don't reach consistency before replaying all of the WAL. Rename the
variable to reachedConsistency, to make its intention clearer.

In master, that was an active bug because of the recent patch to
immediately PANIC if a reference to a missing page is found in WAL after
reaching consistency, as Tom Lane's test case demonstrated. In 9.1 and 9.0,
the only consequence was a misleading "consistent recovery state reached at
%X/%X" message in the log at the beginning of crash recovery (the database
is not consistent at that point yet). In 8.4, the log message was not
printed in crash recovery, even though there was a similar
reachedMinRecoveryPoint local variable that was also set early. So,
backpatch to 9.1 and 9.0.

In pg_upgrade, allow tables using regclass to be upgraded because we
preserve pg_class oids since PG 9.0.

Applied another patch by Zoltan to fix memory alignement issues in ecpg's sqlda
code.

Treat ENOTDIR as ENOENT when looking for client certificate file

This makes it possible to use a libpq app with home directory set
to /dev/null, for example - treating it the same as if the file
doesn't exist (which it doesn't).

Per bug #6302, reported by Diego Elio Petteno

Add some weasel wording about threaded usage of PGresults.

PGresults used to be read-only from the application's viewpoint, but now
that we've exposed various functions that allow modification of a PGresult,
that sweeping statement is no longer accurate.  Noted by Dmitriy Igrishin.

Stamp 9.0.6.

Clarify documentation about SQL:2008 variant of LIMIT/OFFSET syntax.

The point that you need parentheses for non-constant expressions apparently
needs to be brought out a bit more clearly, per bug #6315.

Translation updates

Fix getTypeIOParam to support type record[].

Since record[] uses array_in, it needs to have its element type passed
as typioparam.  In HEAD and 9.1, this fix essentially reverts commit
9bc933b2125a5358722490acbc50889887bf7680, which was a hack that is no
longer needed since domains don't set their typelem anymore.  Before
that, adjust the logic so that only domains are excluded from being
treated like arrays, rather than assuming that only base types should
be included.  Add a regression test to demonstrate the need for this.
Per report from Maxim Boguk.

Back-patch to 8.4, where type record[] was added.

Update information about configuring SysV IPC parameters on NetBSD.

Per Emmanuel Kasper, sysctl works fine as of NetBSD 5.0.

Draft release notes for 9.1.2, 9.0.6, 8.4.10, 8.3.17, 8.2.23.

Update time zone data files to tzdata release 2011n.

DST law changes in Brazil, Cuba, Fiji, Palestine, Russia, Samoa.
Historical corrections for Alaska and British East Africa.

Tweak previous patch to ensure edata->filename always gets initialized.

On a platform that isn't supplying __FILE__, previous coding would either
crash or give a stale result for the filename string.  Not sure how likely
that is, but the original code catered for it, so let's keep doing so.

Strip file names reported in error messages in vpath builds

In vpath builds, the __FILE__ macro that is used in verbose error
reports contains the full absolute file name, which makes the error
messages excessively verbose.  So keep only the base name, thus
matching the behavior of non-vpath builds.

Remove erroneous claim about use of pg_locks.objid for advisory locks.

The correct information appears in the text, so just remove the statement
in the table, where it did not fit nicely anyway.  (Curiously, the correct
info has been there much longer than the erroneous table entry.)
Resolves problem noted by Daniele Varrazzo.

In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.

Backpatch "Use the preferred version of xsubpp."

As requested this is backpatched all the way to release 8.2.

Ensure that whole-row junk Vars are always of composite type.

The EvalPlanQual machinery assumes that whole-row Vars generated for the
outputs of non-table RTEs will be of composite types.  However, for the
case where the RTE is a function call returning a scalar type, we were
doing the wrong thing, as a result of sharing code with a parser case
where the function's scalar output is wanted.  (Or at least, that's what
that case has done historically; it does seem a bit inconsistent.)

To fix, extend makeWholeRowVar's API so that it can support both use-cases.
This fixes Belinda Cussen's report of crashes during concurrent execution
of UPDATEs involving joins to the result of UNNEST() --- in READ COMMITTED
mode, we'd run the EvalPlanQual machinery after a conflicting row update
commits, and it was expecting to get a HeapTuple not a scalar datum from
the "wholerowN" variable referencing the function RTE.

Back-patch to 9.0 where the current EvalPlanQual implementation appeared.

In 9.1 and up, this patch also fixes failure to attach the correct
collation to the Var generated for a scalar-result case.  An example:
regression=# select upper(x.*) from textcat('ab', 'cd') x;
ERROR:  could not determine which collation to use for upper() function

Fix overly-aggressive and inconsistent quoting in OS X start script.

Sidar Lopez, per bug #6310, with some additional improvements by me.
Back-patch to 9.0, where the issue was introduced.

Allow pg_upgrade to upgrade clusters that use exclusion contraints by
fixing pg_dump to properly preserve such indexes.

Backpatch to 9.1 and 9.0 (where the bug was introduced).

Fix erroneous replay of GIN_UPDATE_META_PAGE WAL records.

A simple thinko in ginRedoUpdateMetapage, namely failing to increment a
loop counter, led to inserting records into the last pending-list page in
the wrong order (the opposite of that intended).  So far as I can tell,
this would not upset the code that eventually flushes pending items into
the main part of the GIN index.  But it did break the code that searched
the pending list for matches, resulting in transient failure to find
matching entries during index lookups, as illustrated in bug #6307 from
Maksym Boguk.

Back-patch to 8.4 where the incorrect code was introduced.

Avoid floating-point underflow while tracking buffer allocation rate.

When the system is idle for awhile after activity, the "smoothed_alloc"
state variable in BgBufferSync converges slowly to zero.  With standard
IEEE float arithmetic this results in several iterations with denormalized
values, which causes kernel traps and annoying log messages on some
poorly-designed platforms.  There's no real need to track such small values
of smoothed_alloc, so we can prevent the kernel traps by forcing it to zero
as soon as it's too small to be interesting for our purposes.  This issue
is purely cosmetic, since the iterations don't happen fast enough for the
kernel traps to pose any meaningful performance problem, but still it seems
worth shutting up the log messages.

The kernel log messages were previously reported by a number of people,
but kudos to Greg Matthews for tracking down exactly where they were coming
from.

Applied Zoltan's patch to correctly align interval and timestamp data in ecpg's sqlda.

Don't elide blank lines when accumulating psql command history.

This can change the meaning of queries, if the blank line happens to
occur in the middle of a quoted literal, as per complaint from Tomas Vondra.

Back-patch to all supported branches.

Applied patch by Zoltan to fix copy&paste bug in ecpg's sqlda handling.

Throw nice error if server is too old to support psql's \ef or \sf command.

Previously, you'd get "function pg_catalog.pg_get_functiondef(integer) does
not exist", which is at best rather unprofessional-looking.  Back-patch
to 8.4 where \ef was introduced.

Josh Kupershmidt

Correct documentation for trace_userlocks.

Fix server header file installation with vpath builds

Several server header files would not be installed in vpath builds
because they live in the build directory.

Make DatumGetInetP() unpack inet datums with a 1-byte header, and add
a new macro, DatumGetInetPP(), that does not. This brings these macros
in line with other DatumGet*P() macros.

Backpatch to 8.3, where 1-byte header varlenas were introduced.

-DLINUX_OOM_ADJ=0 should be in CPPFLAGS, not CFLAGS

Fix assorted bugs in contrib/unaccent's configuration file parsing.

Make it use t_isspace() to identify whitespace, rather than relying on
sscanf which is known to get it wrong on some platform/locale combinations.
Get rid of fixed-size buffers.  Make it actually continue to parse the file
after ignoring a line with untranslatable characters, as was obviously
intended.

The first of these issues is per gripe from J Smith, though not exactly
either of his proposed patches.

Don't assume that a tuple's header size is unchanged during toasting.

This assumption can be wrong when the toaster is passed a raw on-disk
tuple, because the tuple might pre-date an ALTER TABLE ADD COLUMN operation
that added columns without rewriting the table.  In such a case the tuple's
natts value is smaller than what we expect from the tuple descriptor, and
so its t_hoff value could be smaller too.  In fact, the tuple might not
have a null bitmap at all, and yet our current opinion of it is that it
contains some trailing nulls.

In such a situation, toast_insert_or_update did the wrong thing, because
to save a few lines of code it would use the old t_hoff value as the offset
where heap_fill_tuple should start filling data.  This did not leave enough
room for the new nulls bitmap, with the result that the first few bytes of
data could be overwritten with null flag bits, as in a recent report from
Hubert Depesz Lubaczewski.

The particular case reported requires ALTER TABLE ADD COLUMN followed by
CREATE TABLE AS SELECT * FROM ... or INSERT ... SELECT * FROM ..., and
further requires that there be some out-of-line toasted fields in one of
the tuples to be copied; else we'll not reach the troublesome code.
The problem can only manifest in this form in 8.4 and later, because
before commit a77eaa6a95009a3441e0d475d1980259d45da072, CREATE TABLE AS or
INSERT/SELECT wouldn't result in raw disk tuples getting passed directly
to heap_insert --- there would always have been at least a junkfilter in
between, and that would reconstitute the tuple header with an up-to-date
t_natts and hence t_hoff.  But I'm backpatching the tuptoaster change all
the way anyway, because I'm not convinced there are no older code paths
that present a similar risk.

Fix archive_command example

The given archive_command example didn't use %p or %f, which wouldn't
really work in practice.

Fix bogus code in contrib/ tsearch dictionary examples.

Both dict_int and dict_xsyn were blithely assuming that whatever memory
palloc gives back will be pre-zeroed.  This would typically work for
just about long enough to run their regression tests, and no longer :-(.

The pre-9.0 code in dict_xsyn was even lamer than that, as it would
happily give back a pointer to the result of palloc(0), encouraging
its caller to access off the end of memory.  Again, this would just
barely fail to fail as long as memory contained nothing but zeroes.

Per a report from Rodrigo Hjort that code based on these examples
didn't work reliably.

Fix inline_set_returning_function() to allow multiple OUT parameters.

inline_set_returning_function failed to distinguish functions returning
generic RECORD (which require a column list in the RTE, as well as run-time
type checking) from those with multiple OUT parameters (which do not).
This prevented inlining from happening.  Per complaint from Jay Levitt.
Back-patch to 8.4 where this capability was introduced.

Revert "Stop btree indexscans upon reaching nulls in either direction."

This reverts commit 7357f92a3ef1faff0ce85f55f3c5a7f4dc820eaa.
As pointed out by Naoya Anzai, we need to do more work to make that
idea handle end-of-index cases, and it is looking like too much risk
for a back-patch.  So bug #6278 is only going to be fixed in HEAD.

Derive oldestActiveXid at correct time for Hot Standby.
There was a timing window between when oldestActiveXid was derived
and when it should have been derived that only shows itself under
heavy load. Move code around to ensure correct timing of derivation.
No change to StartupSUBTRANS() code, which is where this failed.

Bug report by Chris Redekop

Start Hot Standby faster when initial snapshot is incomplete.
If the initial snapshot had overflowed then we can start whenever
the latest snapshot is empty, not overflowed or as we did already,
start when the xmin on primary was higher than xmax of our starting
snapshot, which proves we have full snapshot data.

Bug report by Chris Redekop

Fix timing of Startup CLOG and MultiXact during Hot Standby

Patch by me, bug report by Chris Redekop, analysis by Florian Pflug

Fix race condition with toast table access from a stale syscache entry.

If a tuple in a syscache contains an out-of-line toasted field, and we
try to fetch that field shortly after some other transaction has committed
an update or deletion of the tuple, there is a race condition: vacuum
could come along and remove the toast tuples before we can fetch them.
This leads to transient failures like "missing chunk number 0 for toast
value NNNNN in pg_toast_2619", as seen in recent reports from Andrew
Hammond and Tim Uckun.

The design idea of syscache is that access to stale syscache entries
should be prevented by relation-level locks, but that fails for at least
two cases where toasted fields are possible: ANALYZE updates pg_statistic
rows without locking out sessions that might want to plan queries on the
same table, and CREATE OR REPLACE FUNCTION updates pg_proc rows without
any meaningful lock at all.

The least risky fix seems to be an idea that Heikki suggested when we
were dealing with a related problem back in August: forcibly detoast any
out-of-line fields before putting a tuple into syscache in the first place.
This avoids the problem because at the time we fetch the parent tuple from
the catalog, we should be holding an MVCC snapshot that will prevent
removal of the toast tuples, even if the parent tuple is outdated
immediately after we fetch it.  (Note: I'm not convinced that this
statement holds true at every instant where we could be fetching a syscache
entry at all, but it does appear to hold true at the times where we could
fetch an entry that could have a toasted field.  We will need to be a bit
wary of adding toast tables to low-level catalogs that don't have them
already.)  An additional benefit is that subsequent uses of the syscache
entry should be faster, since they won't have to detoast the field.

Back-patch to all supported versions.  The problem is significantly harder
to reproduce in pre-9.0 releases, because of their willingness to flush
every entry in a syscache whenever the underlying catalog is vacuumed
(cf CatalogCacheFlushRelation); but there is still a window for trouble.

Document that multiple LDAP servers can be specified

Stop btree indexscans upon reaching nulls in either direction.

The existing scan-direction-sensitive tests were overly complex, and
failed to stop the scan in cases where it's perfectly legitimate to do so.
Per bug #6278 from Maksym Boguk.

Back-patch to 8.3, which is as far back as the patch applies easily.
Doesn't seem worth sweating over a relatively minor performance issue in
8.2 at this late date.  (But note that this was a performance regression
from 8.1 and before, so 8.2 is being left as an outlier.)

Fix assorted bogosities in cash_in() and cash_out().

cash_out failed to handle multiple-byte thousands separators, as per bug
#6277 from Alexander Law.  In addition, cash_in didn't handle that either,
nor could it handle multiple-byte positive_sign.  Both routines failed to
support multiple-byte mon_decimal_point, which I did not think was worth
changing, but at least now they check for the possibility and fall back to
using '.' rather than emitting invalid output.  Also, make cash_in handle
trailing negative signs, which formerly it would reject.  Since cash_out
generates trailing negative signs whenever the locale tells it to, this
last omission represents a fail-to-reload-dumped-data bug.  IMO that
justifies patching this all the way back.

Update docs to point to the timezone library's new home at IANA.

The recent unpleasantness with copyrights has accelerated a move that
was already in planning.

Change FK trigger creation order to better support self-referential FKs.

When a foreign-key constraint references another column of the same table,
row updates will queue both the PK's ON UPDATE action and the FK's CHECK
action in the same event.  The ON UPDATE action must execute first, else
the CHECK will check a non-final state of the row and possibly throw an
inappropriate error, as seen in bug #6268 from Roman Lytovchenko.

Now, the firing order of multiple triggers for the same event is determined
by the sort order of their pg_trigger.tgnames, and the auto-generated names
we use for FK triggers are "RI_ConstraintTrigger_NNNN" where NNNN is the
trigger OID.  So most of the time the firing order is the same as creation
order, and so rearranging the creation order fixes it.

This patch will fail to fix the problem if the OID counter wraps around or
adds a decimal digit (eg, from 99999 to 100000) while we are creating the
triggers for an FK constraint.  Given the small odds of that, and the low
usage of self-referential FKs, we'll live with that solution in the back
branches.  A better fix is to change the auto-generated names for FK
triggers, but it seems unwise to do that in stable branches because there
may be client code that depends on the naming convention.  We'll fix it
that way in HEAD in a separate patch.

Back-patch to all supported branches, since this bug has existed for a long
time.

Don't trust deferred-unique indexes for join removal.

The uniqueness condition might fail to hold intra-transaction, and assuming
it does can give incorrect query results.  Per report from Marti Raudsepp,
though this is not his proposed patch.

Back-patch to 9.0, where both these features were introduced.  In the
released branches, add the new IndexOptInfo field to the end of the struct,
to try to minimize ABI breakage for third-party code that may be examining
that struct.

Fix pg_dump to dump casts between auto-generated types.

The heuristic for when to dump a cast failed for a cast between table
rowtypes, as reported by Frédéric Rejol.  Fix it by setting
the "dump" flag for such a type the same way as the flag is set for the
underlying table or base type.  This won't result in the auto-generated
type appearing in the output, since setting its objType to DO_DUMMY_TYPE
unconditionally suppresses that.  But it will result in dumpCast doing what
was intended.

Back-patch to 8.3.  The 8.2 code is rather different in this area, and it
doesn't seem worth any risk to fix a corner case that nobody has stumbled
on before.

Fix bugs in information_schema.referential_constraints view.

This view was being insufficiently careful about matching the FK constraint
to the depended-on primary or unique key constraint.  That could result in
failure to show an FK constraint at all, or showing it multiple times, or
claiming that it depended on a different constraint than the one it really
does.  Fix by joining via pg_depend to ensure that we find only the correct
dependency.

Back-patch, but don't bump catversion because we can't force initdb in back
branches.  The next minor-version release notes should explain that if you
need to fix this in an existing installation, you can drop the
information_schema schema then re-create it by sourcing
$SHAREDIR/information_schema.sql in each database (as a superuser of
course).

Modify up/home macro to match standard parameter list;  fixes doc build.

Improve documentation of psql's \q command.

The documentation neglected to explain its behavior in a script file
(it only ends execution of the script, not psql as a whole), and failed
to mention the long form \quit either.

Add Up/Home link to the top of the HTML doc output.

Backpatch to 9.0.X and 9.1.X.

Fix typo in docs for libpq keepalives_count option.

Shigehiro Honda

Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.
transform_null_equals is only supposed to affect "foo = NULL" expressions
given directly by the user, not the internal "foo = NULL" expression
generated from CASE-WHEN.

This fixes bug #6242, reported by Sergey. Backpatch to all supported
branches.

Make pgstatindex respond to cancel interrupts.

A similar problem for pgstattuple() was fixed in April of 2010 by commit
33065ef8bc52253ae855bc959576e52d8a28ba06, but pgstatindex() seems to have
been overlooked.

Back-patch all the way, as with that commit, though not to 7.4 through
8.1, since those are now EOL.

Add sourcefile/sourceline data to EXEC_BACKEND GUC transmission files.

This oversight meant that on Windows, the pg_settings view would not
display source file or line number information for values coming from
postgresql.conf, unless the backend had received a SIGHUP since starting.

In passing, also make the error detection in read_nondefault_variables a
tad more thorough, and fix it to not lose precision on float GUCs (these
changes are already in HEAD as of my previous commit).

ProcedureCreate neglected to record dependencies on default expressions.

Thus, an object referenced in a default expression could be dropped while
the function remained present.  This was unaccountably missed in the
original patch to add default parameters for functions.  Reported by
Pavel Stehule.

Fix typo

Note that sslmode=require verifies the CA if root cert is present

This mode still exists for backwards compatibility, making
sslmode=require the same as sslmode=verify-ca when the file is present,
but not causing an error when it isn't.

Per bug 6189, reported by Srinivas Aji

Fix our mapping of Windows timezones for Central America.

We were mapping "Central America Standard Time" to "CST6CDT", which seems
entirely wrong, because according to the Olson timezone database noplace
in Central America observes daylight savings time on any regular basis ---
and certainly not according to the USA DST rules that are implied by
"CST6CDT".  (Mexico is an exception, but they can be disregarded since
they have a separate timezone name in Windows.)  So, map this zone name to
plain "CST6", which will provide a fixed UTC offset.

As written, this patch will also result in mapping "Central America
Daylight Time" to CST6.  I considered hacking things so that would still
map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those
two names in separate entries.  Since there's little evidence that any
such zone name is used in the wild, much less that CST6CDT would be a good
match for it, I'm not too worried about what we do with it.

Per complaint from Pratik Chirania.

Stamp 9.0.5.

Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22.

Man, we fixed a lotta bugs since April.

Translation updates

gistendscan() forgot to free so->giststate.

This oversight led to a massive memory leak --- upwards of 10KB per tuple
--- during creation-time verification of an exclusion constraint based on a
GIST index.  In most other scenarios it'd just be a leak of 10KB that would
be recovered at end of query, so not too significant; though perhaps the
leak would be noticeable in a situation where a GIST index was being used
in a nestloop inner indexscan.  In any case, it's a real leak of long
standing, so patch all supported branches.  Per report from Harald Fuchs.

deflist_to_tuplestore dumped core on an option with no value.

Make it return NULL for the option_value, instead.

Per report from Frank van Vugt.  Back-patch to 8.4 where this code was
added.

Fix permissions on pg_largeobject_metadata.h in 9.0 branch.

For some reason it was 0755 instead of 0644.

Add missing format argument to ecpg_log() call

Fix corner case bug in numeric to_char().

Trailing-zero stripping applied by the FM specifier could strip zeroes
to the left of the decimal point, for a format with no digit positions
after the decimal point (such as "FM999.").

Reported and diagnosed by Marti Raudsepp, though I didn't use his patch.

In pg_upgrade, disallow migration of 8.3 clusters using contrib/ltree
because its internal format was changed in 8.4.

Backpatch to 9.0 and 9.1.

Report by depesz, diagnosis by Tom.

Revert documentation patch about NEW/OLD and triggers.

Backpatch to 9.0 and 9.1.

Patch from Josh Kupershmidt.

Properly document the existance of OLD/NEW trigger pl/pgsql trigger
fields.

Backpatch to 9.0 and 9.1.

Report from Pavel Stehule, patch from Josh Kupershmidt

Fix plpgsql "PERFORM" markup.

Backpatch to 9.0 and 9.1.

Avoid possibly accessing off the end of memory in SJIS2004 conversion.

The code in shift_jis_20042euc_jis_2004() would fetch two bytes even when
only one remained in the string.  Since conversion functions aren't
supposed to assume null-terminated input, this poses a small risk of
fetching past the end of memory and incurring SIGSEGV.  No such crash has
been identified in the field, but we've certainly seen the equivalent
happen in other code paths, so patch this one all the way back.

Report and patch by Noah Misch.

Avoid possibly accessing off the end of memory in examine_attribute().

Since the last couple of columns of pg_type are often NULL,
sizeof(FormData_pg_type) can be an overestimate of the actual size of the
tuple data part.  Therefore memcpy'ing that much out of the catalog cache,
as analyze.c was doing, poses a small risk of copying past the end of
memory and incurring SIGSEGV.  No such crash has been identified in the
field, but we've certainly seen the equivalent happen in other code paths,
so patch this one all the way back.

Per valgrind testing by Noah Misch, though this is not his proposed patch.
I chose to use SearchSysCacheCopy1 rather than inventing special-purpose
infrastructure for copying only the minimal part of a pg_type tuple.

Document PERFORM limitation when using WITH queries.

Backpatch to 9.0 and 9.1.

Report from depstein@alliedtesting.com.

Update type-conversion documentation for long-ago changes.

This example wasn't updated when we changed the behavior of bpcharlen()
in 8.0, nor when we changed the number of parameters taken by the bpchar()
cast function in 7.3.  Per report from lsliang.

Properly document semphore requirements by accounting for worker
processes.

Backpatch to 9.1 and 9.0.

Submitted by Anton Yuzhaninov, confirmed by Robert Haas

Update time zone data files to tzdata release 2011i.

DST law changes in Canada, Egypt, Russia, Samoa, South Sudan.

Document that contrib/pgtrgm only processes ASCII alphanumeric
characters.

Backpatch to 9.0 and 9.1.

Guard against using plperl's Makefile without specifying --with-perl.

The $(PERL) macro will be set by configure if it finds perl at all,
but $(perl_privlibexp) isn't configured unless you said --with-perl.
This results in confusing error messages if someone cd's into
src/pl/plperl and tries to build there despite the configure omission,
as reported by Tomas Vondra in bug #6198.  Add simple checks to
provide a more useful report, while not disabling other use of the
makefile such as "make clean".

Back-patch to 9.0, which is as far as the patch applies easily.

Fix typo in pg_srand48 (srand48 in older branches).

">" should be ">>".  This typo results in failure to use all of the bits
of the provided seed.

This might rise to the level of a security bug if we were relying on
srand48 for any security-critical purposes, but we are not --- in fact,
it's not used at all unless the platform lacks srandom(), which is
improbable.  Even on such a platform the exposure seems minimal.

Reported privately by Andres Freund.

Fix brace indentation of commit f8c74422010e63506fa69635ea61920bc042b70e to fit PostgreSQL style.

In ecpglib restore LC_NUMERIC in case of an error.

Move the line to undefine setlocale() macro on Win32 outside USE_REPL_SNPRINTF
ifdef block. It has nothing to do with whether the replacement snprintf
function is used. It caused no live bug, because the replacement snprintf
function is always used on Win32, but it was nevertheless misplaced.

Further repair of eqjoinsel ndistinct-clamping logic.

Examination of examples provided by Mark Kirkwood and others has convinced
me that actually commit 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 was quite
a few bricks shy of a load.  The useful part of that patch was clamping
ndistinct for the inner side of a semi or anti join, and the reason why
that's needed is that it's the only way that restriction clauses
eliminating rows from the inner relation can affect the estimated size of
the join result.  I had not clearly understood why the clamping was
appropriate, and so mis-extrapolated to conclude that we should clamp
ndistinct for the outer side too, as well as for both sides of regular
joins.  These latter actions were all wrong, and are reverted with this
patch.  In addition, the clamping logic is now made to affect the behavior
of both paths in eqjoinsel_semi, with or without MCV lists to compare.
When we have MCVs, we suppose that the most common values are the ones
that are most likely to survive the decimation resulting from a lower
restriction clause, so we think of the clamping as eliminating non-MCV
values, or potentially even the least-common MCVs for the inner relation.

Back-patch to 8.4, same as previous fixes in this area.

Fix pg_upgrade to preserve toast relfrozenxids for old 8.3 servers.

This fixes a pg_upgrade bug that could lead to query errors when
clog files are improperly removed.

Backpatch to 8.4, 9.0, 9.1.

Improve eqjoinsel's ndistinct clamping to work for multiple levels of join.

This patch fixes an oversight in my commit
7f3eba30c9d622d1981b1368f2d79ba0999cdff2 of 2008-10-23.  That patch
accounted for baserel restriction clauses that reduced the number of rows
coming out of a table (and hence the number of possibly-distinct values of
a join variable), but not for join restriction clauses that might have been
applied at a lower level of join.  To account for the latter, look up the
sizes of the min_lefthand and min_righthand inputs of the current join,
and clamp with those in the same way as for the base relations.

Noted while investigating a complaint from Ben Chobot, although this in
itself doesn't seem to explain his report.

Back-patch to 8.4; previous versions used different estimation methods
for which this heuristic isn't relevant.

Fix a missed case in code for "moving average" estimate of reltuples.

It is possible for VACUUM to scan no pages at all, if the visibility map
shows that all pages are all-visible.  In this situation VACUUM has no new
information to report about the relation's tuple density, so it wasn't
changing pg_class.reltuples ... but it updated pg_class.relpages anyway.
That's wrong in general, since there is no evidence to justify changing the
density ratio reltuples/relpages, but it's particularly bad if the previous
state was relpages=reltuples=0, which means "unknown tuple density".
We just replaced "unknown" with "zero".  ANALYZE would eventually recover
from this, but it could take a lot of repetitions of ANALYZE to do so if
the relation size is much larger than the maximum number of pages ANALYZE
will scan, because of the moving-average behavior introduced by commit
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8.

The only known situation where we could have relpages=reltuples=0 and yet
the visibility map asserts everything's visible is immediately following
a pg_upgrade.  It might be advisable for pg_upgrade to try to preserve the
relpages/reltuples statistics; but in any case this code is wrong on its
own terms, so fix it.  Per report from Sergey Koposov.

Back-patch to 8.4, where the visibility map was introduced, same as the
previous change.

Actually, all of parallel restore's limitations should be tested earlier.

On closer inspection, whining in restore_toc_entries_parallel is really
much too late for any user-facing error case.  The right place to do it
is at the start of RestoreArchive(), before we've done anything interesting
(suh as trying to DROP all the targets ...)

Back-patch to 8.4, where parallel restore was introduced.

Be more user-friendly about unsupported cases for parallel pg_restore.

If we are unable to do a parallel restore because the input file is stdin
or is otherwise unseekable, we should complain and fail immediately, not
after having done some of the restore.  Complaining once per thread isn't
so cool either, and the messages should be worded to make it clear this is
an unsupported case not some weird race-condition bug.  Per complaint from
Lonni Friedman.

Back-patch to 8.4, where parallel restore was introduced.

Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.

These days, such a response is far more likely to signify a server-side
problem, such as fork failure.  Reporting "server does not support SSL"
(in sslmode=require) could be quite misleading.  But the results could
be even worse in sslmode=prefer: if the problem was transient and the
next connection attempt succeeds, we'll have silently fallen back to
protocol version 2.0, possibly disabling features the user needs.

Hence, it seems best to just eliminate the assumption that backing off
to non-SSL/2.0 protocol is the way to recover from an "E" response, and
instead treat the server error the same as we would in non-SSL cases.

I tested this change against a pre-7.0 server, and found that there
was a second logic bug in the "prefer" path: the test to decide whether
to make a fallback connection attempt assumed that we must have opened
conn->ssl, which in fact does not happen given an "E" response.  After
fixing that, the code does indeed connect successfully to pre-7.0,
as long as you didn't set sslmode=require.  (If you did, you get
"Unsupported frontend protocol", which isn't completely off base
given the server certainly doesn't support SSL.)

Since there seems no reason to believe that pre-7.0 servers exist anymore
in the wild, back-patch to all supported branches.