This reverts commit 0180bd61.
contrib/userlock is gone, but user-level locking still exists,
and is exposed via the pg_advisory* family of functions.

Backpatch to 9.1.

Mark Hills

non_empty(anyrange) function was removed, empty(anyrange) was renamed to
isempty(anyrange), and !? operators were removed.

Since PostgreSQL 9.0, we've emitted a warning message when an operator
named => is created, because the SQL standard now reserves that token
for another use.  But we've also shipped such an operator with hstore.
Use of the function hstore(text, text) has been recommended in
preference to =>(text, text).  Per discussion, it's now time to take
the next step and stop shipping the operator.  This will allow us to
prohibit the use of => as an operator name in a future release if and
when we wish to support the SQL standard use of this token.

The release notes should mention this incompatibility.

Patch by me, reviewed by David Wheeler, Dimitri Fontaine and Tom Lane.

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

Document that this rule applies to 'samerole' as well as to named roles.

Per gripe from Tom Lane.

This makes it possible to use reject lines with group roles.

Andrew Dunstan, reviewd by Robert Haas.

Selectivity estimation functions are missing for some range type operators,
which is a TODO.

Jeff Davis

Greg Smith

Kevin Grittner

Report by Vik Reykja, patch by Kevin Grittner.

expect -> except, noted by Andrew Dunstan.  Also, "cannot" seems more
readable here than "can not", per David Wheeler.

Add option for parallel streaming of the transaction log while a
base backup is running, to get the logfiles before the server has
removed them.

Also add a tool called pg_receivexlog, which streams the transaction
log into files, creating a log archive without having to wait for
segments to complete, thus decreasing the window of data loss without
having to waste space using archive_timeout. This works best in
combination with archive_command - suggested usage docs etc coming later.

This allows different instances to use the eventlog with different
identifiers, by setting the event_source GUC, similar to how
syslog_ident works.

Original patch by MauMau, heavily modified by Magnus Hagander

A transaction can export a snapshot with pg_export_snapshot(), and then
others can import it with SET TRANSACTION SNAPSHOT.  The data does not
leave the server so there are not security issues.  A snapshot can only
be imported while the exporting transaction is still running, and there
are some other restrictions.

I'm not totally convinced that we've covered all the bases for SSI (true
serializable) mode, but it works fine for lesser isolation modes.

Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified
by Tom Lane

Fujii Masao

Josh Kupershmidt, reviewed by Fujii Masao

In general the data returned by an index-only scan should have the
datatypes originally computed by FormIndexDatum.  If the index opclasses
use "storage" datatypes different from their input datatypes, the scan
tuple will not have the same rowtype attributed to the index; but we had
a hard-wired assumption that that was true in nodeIndexonlyscan.c.  We'd
already hacked around the issue for the one case where the types are
different in btree indexes (btree name_ops), but this would definitely
come back to bite us if we ever implement index-only scans in GiST.

To fix, require the index AM to explicitly provide the tupdesc for the
tuple it is returning.  btree can just pass back the index's tupdesc, but
GiST will have to work harder when and if it supports index-only scans.

I had previously proposed fixing this by allowing the index AM to fill the
scan tuple slot directly; but on reflection that seemed like a module
layering violation, since TupleTableSlots are creatures of the executor.
At least in the btree case, it would also be less efficient, since the
tuple deconstruction work would occur even for rows later found to be
invisible to the scan's snapshot.

This allows "indexedcol op ANY(ARRAY[...])" conditions to be used in plain
indexscans, and particularly in index-only scans.

Rearrange text to improve clarity, and add an example of implicit reference
to a plpgsql variable in a bound cursor's query.  Byproduct of some work
I'd done on the "named cursor parameters" patch before giving up on it.

that controls .psqlrc.

matching version file does not exist.  This avoids needing to rename
.psqlrc files after minor version upgrades.

Add a column pg_class.relallvisible to remember the number of pages that
were all-visible according to the visibility map as of the last VACUUM
(or ANALYZE, or some other operations that update pg_class.relpages).
Use relallvisible/relpages, instead of an arbitrary constant, to estimate
how many heap page fetches can be avoided during an index-only scan.

This is pretty primitive and will no doubt see refinements once we've
acquired more field experience with the index-only scan mechanism, but
it's way better than using a constant.

Note: I had to adjust an underspecified query in the window.sql regression
test, because it was changing answers when the plan changed to use an
index-only scan.  Some of the adjacent tests perhaps should be adjusted
as well, but I didn't do that here.

authentication.

Report and pseudo code by Cyan Ogilvie

in PG 8.2.

match the Linux Standard Base Core Specification 3.1.

Aaron W. Swenson

dummy_label -> dummy_seclabel

Thom Brown

not matching the primary key.

Report from Marek.Balgar@seznam.cz

We have seen one too many reports of people trying to use 9.1 extension
files in the old-fashioned way of sourcing them in psql.  Not only does
that usually not work (due to failure to substitute for MODULE_PATHNAME
and/or @extschema@), but if it did work they'd get a collection of loose
objects not an extension.  To prevent this, insert an \echo ... \quit
line that prints a suitable error message into each extension script file,
and teach commands/extension.c to ignore lines starting with \echo.
That should not only prevent any adverse consequences of loading a script
file the wrong way, but make it crystal clear to users that they need to
do it differently now.

Tom Lane, following an idea of Andrew Dunstan's.  Back-patch into 9.1
... there is not going to be much value in this if we wait till 9.2.