than replication_timeout (a new GUC) milliseconds. The TCP timeout is often
too long, you want the master to notice a dead connection much sooner.
People complained about that in 9.0 too, but with synchronous replication
it's even more important to notice dead connections promptly.

Fujii Masao and Heikki Linnakangas

close at this point. Fix PQsetnonblocking() comment.

Fujii Masao

Feature F692 "Extended collation support" is now also supported.  This
refers to allowing the COLLATE clause anywhere in a column or domain
definition instead of just directly after the type.

Also correct the name of the feature in accordance with the latest SQL
standard.

This can do various source code checks that are not appropriate for
either the build or the regression tests.  Currently: duplicate_oids,
SGML syntax and tabs check, NLS syntax check.

Automatic detection of errors is easier that way.

Eventually we might be able to allow that, but it's not clear how many
places need to be fixed to prevent infinite recursion when there's a direct
or indirect inclusion of a rowtype in itself.  One such place is
CheckAttributeType(), which will recurse to stack overflow in cases such as
those exhibited in bug #5950 from Alex Perepelica.  If we were sure it was
the only such place, we could easily modify the code added by this patch to
stop the recursion without a complaint ... but it probably isn't the only
such place.  Hence, throw error until such time as someone is excited
enough about this type of usage to put work into making it safe.

Back-patch as far as 8.3.  8.2 doesn't have the recursive call in
CheckAttributeType in the first place, so I see no need to add code there
in the absence of clear evidence of a problem elsewhere.

We already had links to the GUC variables that control it.

Unlike <xref>, this actually works.

Kevin Grittner

Susanne Ebrecht

This fixes the gripe I made a few months ago about DO blocks getting
slower with repeated use.  At least, it fixes it for the case where
the DO block isn't aborted by an error.  We could try running
plpgsql_free_function_memory() even during error exit, but that seems
a bit scary since it makes a lot of presumptions about the data
structures being in good shape.  It's probably reasonable to assume
that repeated failures of DO blocks isn't a performance-critical case.

The underlying problem that caused this phenomenon was fixed by commit
92f4786f.

In addition, correct the entry for pg_object_description, and some other
minor cleanup.

I found actual bugs in GiST and plpgsql; the rest of this is cosmetic
but meant to decrease the odds of future bugs of omission.

Mostly cosmetic, though I did find that generateClonedIndexStmt failed
to clone the index's collations.

I'm not sure these have any non-cosmetic implications, but I'm not sure
they don't, either.  In particular, ensure the CaseTestExpr generated
by transformAssignmentIndirection to represent the base target column
carries the correct collation, because parse_collate.c won't fix that.
Tweak lsyscache.c API so that we can get the appropriate collation
without an extra syscache lookup.

possibility of race condition that would effect performance only.
Requested by Robert Haas. Re-arrange related comments.

In nearly all cases, the caller already knows the correct collation, and
in a number of places, the value the caller has handy is more correct than
the default for the type would be.  (In particular, this patch makes it
significantly less likely that eval_const_expressions will result in
changing the exposed collation of an expression.)  So an internal lookup
is both expensive and wrong.

Turns out it was this, and not so much plpgsql, that was at fault in Stefan
Huehner's collation-error-in-a-trigger bug report of a couple weeks ago.

This is pretty minimal but covers the bare facts.

Make plpgsql treat the input collation as a polymorphism variable, so
that we cache separate plans for each input collation that's used in a
particular session, as per recent discussion.  Propagate the input
collation to all collatable input parameters.

I chose to also propagate the input collation to all declared variables of
collatable types, which is a bit more debatable but seems to be necessary
for non-astonishing behavior.  (Copying a parameter into a separate local
variable shouldn't result in a change of behavior, for example.)  There is
enough infrastructure here to support declaring a collation for each local
variable to override that default, but I thought we should wait to see what
the field demand is before adding such a feature.

In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere.

Documentation patch to follow.

Temporarily move some of the alpha release note disclaimers into the regular
release notes, for the sake of alpha5.

It originally worked this way, but was changed by commit
a8a8a3e0, since which time it's been impossible
for walreceiver to ever send a reply with write_location and flush_location
set to different values.

-r no_indicator
-r prepare
-r questionsmarks

Ensure that parameter symbols receive collation from the function's
resolved input collation, and fix inlining to behave properly.

BTW, this commit lays about 90% of the infrastructure needed to support
use of argument names in SQL functions.  Parsing of parameters is now
done via the parser-hook infrastructure ... we'd just need to supply
a column-ref hook ...

KaiGai Kohei

Add some new items and some additional details to existing items, mostly
by cribbing from the 9.1alpha notes.  Some additional clarifications and
corrections elsewhere, and a few typo fixes.

Ensure that COLLATE at the top level of an index expression is treated the
same as a grammatically separate COLLATE.  Fix bogus reverse-parsing logic
in pg_get_indexdef.

On closer inspection, that two-element initcond value seems to have been
a little white lie to avoid explaining the full behavior of float8_accum.
But if people are going to expect the examples to be exactly correct,
I suppose we'd better explain.  Per comment from Thom Brown.

Change location LOG message so it works each time we pause, not
just for final pause.
Ensure that we pause only if we are in Hot Standby and can connect
to allow us to run resume function. This change supercedes the
code to override parameter recoveryPauseAtTarget to false if not
attempting to enter Hot Standby, which is now removed.

The description of the initcond value for the built-in avg(float8)
aggregate has been wrong since it was written.  Noted by Disc Magnet.

This is no longer necessary, and might result in a situation where the
configuration file is reloaded (and everything seems OK) but a subsequent
restart of the database fails.

Per an observation from Fujii Masao.

Startup process waited for cleanup lock but when hot_standby = off
the pid was not registered, so that the bgwriter would not wake
the waiting process as intended.