delta/postgresql.git, branch REL9_0_11

Stamp 9.0.11.

2012-12-03T20:22:30+00:00

Update release notes for 9.2.2, 9.1.7, 9.0.11, 8.4.15, 8.3.22.

2012-12-03T20:10:17+00:00

Revert "Add mode where contrib installcheck runs each module in a separately named database."

2012-12-03T20:03:50+00:00

This reverts commit c8f666abde2af3060af41afe4b03ced2f62d94a9.

Avoid holding vmbuffer pin after VACUUM.

2012-12-03T18:56:41+00:00

During VACUUM if we pause to perform a cycle
of index cleanup we drop the vmbuffer pin,
so we should do the same thing when heap
scan completes. This avoids holding vmbuffer
pin across the main index cleanup in VACUUM,
which could be minutes or hours longer than
necessary for correctness.

Bug report and suggested fix from Pavan Deolasee

Fix documentation of path(polygon) function.

2012-12-03T16:09:04+00:00

Obviously, this returns type "path", but somebody made a copy-and-pasteo
long ago.

Dagfinn Ilmari Mannsåker

Translation updates

2012-12-03T12:52:39+00:00

Add mode where contrib installcheck runs each module in a separately named database.

2012-12-02T22:30:18+00:00

Normally each module is tested in aq database named contrib_regression,
which is dropped and recreated at the beginhning of each pg_regress run.
This mode, enabled by adding USE_MODULE_DB=1 to the make command line,
runs most modules in a database with the module name embedded in it.

This will make testing pg_upgrade on clusters with the contrib modules
a lot easier.

Still to be done: adapt to the MSVC build system.

Backpatch to 9.0, which is the earliest version it is reasonably
possible to test upgrading from.

Update time zone data files to tzdata release 2012j.

2012-12-02T21:36:18+00:00

DST law changes in Cuba, Israel, Jordan, Libya, Palestine, Western Samoa,
and portions of Brazil.

Don't advance checkPoint.nextXid near the end of a checkpoint sequence.

2012-12-02T20:20:15+00:00

This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef in favor of
actually fixing the problem: namely, that we should never have been
modifying the checkpoint record's nextXid at this point to begin with.
The nextXid should match the state as of the checkpoint's logical WAL
position (ie the redo point), not the state as of its physical position.
It's especially bogus to advance it in some wal_levels and not others.
In any case there is no need for the checkpoint record to carry the
same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by
LogStandbySnapshot, as any replay operation will already have adopted
that value as current.

This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug
#6291 from Daniel Farina, in that if a checkpoint were in progress at the
instant of XID wraparound, the epoch bump would be lost as reported.
(And, of course, these days there's at least a 50-50 chance of a checkpoint
being in progress at any given instant.)

Diagnosed by me and independently by Andres Freund.  Back-patch to all
branches supporting hot standby.

XidEpoch++ if wraparound during checkpoint.

2012-12-02T15:02:28+00:00

If wal_level = hot_standby we update the checkpoint nextxid,
though in the case where a wraparound occurred half-way through
a checkpoint we would neglect updating the epoch also. Updating
the nextxid is arguably the wrong thing to do, but changing that
may introduce subtle bugs into hot standby startup, while updating
the value doesn't cause any known bugs yet. Minimal fix now to
HEAD and backbranches, wider fix later in HEAD.

Bug reported in #6291 by Daniel Farina and slightly differently in

Cause analysis and recommended fixes from Tom Lane and Andres Freund.

Applied patch is minimal version of Andres Freund's work.