< 	o Prevent pg_dump/pg_restore from being affected by
> 	o -Prevent pg_dump/pg_restore from being affected by

Per buildfarm results.

>
> 	o Allow COPY to report errors sooner
>
>          http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php

Joshua D. Drake

> * Allow custom variables to appear in pg_settings()

* Implement a module capability for loading /contrib-style extensions

  http://archives.postgresql.org/pgsql-patches/2008-04/msg00164.php

binary values.

Add comments to libpq C function for parameter passing.

* Consider whether duplicate keys should be sorted by block/offset

  http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php

Create new "Sorting" TODO section.

formatting.c to use common code;  remove duplicate functions and support
routines that are no longer needed.

in pg_proc.  Also make it not emit duplicate extern declarations, and make it
a bit more bulletproof in some other small ways.  Likewise fix the equally
hard-wired, and utterly undocumented, knowledge in the MSVC build scripts.
For testing purposes and perhaps other uses in future, pull out that portion
of the MSVC scripts into a standalone perl script equivalent to
Gen_fmgrtab.sh, and make it generate actually identical output, rather than
just more-or-less-the-same output.

Motivated by looking at Pavel's variadic function patch.  Whether or not
that gets accepted, we can be sure that pg_proc's column set will change
again in the future; it's time to not have to deal with this gotcha.

read and written without a lock.  The value itself is atomic, sure, but on
processors with weak memory ordering it's possible for a reader to see the
value change before it sees the associated message written into the buffer
array.  Fix by introducing a spinlock that's used just to read and write
maxMsgNum.  (We could do this with less overhead if we recognized a concept
of "memory access barrier"; is it worth introducing such a thing?  At the
moment probably not --- I can't measure any clear slowdown from adding the
spinlock, so this solution is probably fine.)  Per buildfarm results.

unnecessary cache resets.  The major changes are:

* When the queue overflows, we only issue a cache reset to the specific
backend or backends that still haven't read the oldest message, rather
than resetting everyone as in the original coding.

* When we observe backend(s) falling well behind, we signal SIGUSR1
to only one backend, the one that is furthest behind and doesn't already
have a signal outstanding for it.  When it finishes catching up, it will
in turn signal SIGUSR1 to the next-furthest-back guy, if there is one that
is far enough behind to justify a signal.  The PMSIGNAL_WAKEN_CHILDREN
mechanism is removed.

* We don't attempt to clean out dead messages after every message-receipt
operation; rather, we do it on the insertion side, and only when the queue
fullness passes certain thresholds.

* Split SInvalLock into SInvalReadLock and SInvalWriteLock so that readers
don't block writers nor vice versa (except during the infrequent queue
cleanout operations).

* Transfer multiple sinval messages for each acquisition of a read or
write lock.

parsing.  Per bug #4253 from Giorgio Valoti.

        o Allow pg_hba.conf to specify host names along with IP addresses
> 	  http://archives.postgresql.org/pgsql-hackers/2008-06/msg00569.php

corresponding struct definitions.  This allows other headers to avoid including
certain highly-loaded headers such as rel.h and relscan.h, instead using just
relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less
unnecessary dependencies.

by installing an error context subroutine that will provide the file name
and line number for all errors detected while reading a config file.
Some of the reader routines were already doing that in an ad-hoc way for
errors detected directly in the reader, but it didn't help for problems
detected in subroutines, such as encoding violations.

Back-patch to 8.3 because 8.3 is where people will be trying to debug
configuration files.

use for other modules;  also move pnstrdup().

Clean up code slightly.

along with an additional typo I noticed along the way.

use it to help enforce superuser_reserved_backends, but since 8.1 it's
just been dead weight.

int2-and-int8 implementations of the basic arithmetic operators +, -, *, /.
This doesn't really add any new functionality, but it avoids "operator is not
unique" failures that formerly occurred in these cases because the parser
couldn't decide whether to promote the int2 to int4 or int8.  We could
alternatively have removed the existing cross-type operators, but
experimentation shows that the cost of an additional type coercion expression
node is noticeable compared to such cheap operators; so let's not give up any
performance here.  On the other hand, I removed the int2-and-int4 modulo (%)
operators since they didn't seem as important from a performance standpoint.
Per a complaint last January from ykhuang.

USE_WIDE_UPPER_LOWER instead.

that it depends on for replan-forcing purposes.  We need to consider plain OID
constants too, because eval_const_expressions folds a RelabelType atop a Const
to just a Const.  This change could result in OID values that aren't really
for tables getting added to the dependency list, but the worst-case
consequence would be occasional useless replans.  Per report from Gabriele
Messineo.

1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult.  This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result.  (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)

2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.

3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings.  This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.

#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(

late, with lots of redundancy, bad grammar, and just plain poor exposition.
Make it clear that autovacuum is now considered the normal solution.

and add them. Avoids third party files or those that would cause regression
failures.

is necessary to avoid deadlock against ordinary queries, but we'd broken it
with recent changes that made the DROP machinery lock the index before
arriving at index_drop.  Per intermittent buildfarm failures.

grammar allows ALTER TABLE/INDEX/SEQUENCE/VIEW interchangeably for all
subforms of those commands, and then we sort out what's really legal
at execution time.  This allows the ALTER SEQUENCE/VIEW reference pages
to fully document all the ALTER forms available for sequences and views
respectively, and eliminates a longstanding cause of confusion for users.

The net effect is that the following forms are allowed that weren't before:
	ALTER SEQUENCE OWNER TO
	ALTER VIEW ALTER COLUMN SET/DROP DEFAULT
	ALTER VIEW OWNER TO
	ALTER VIEW SET SCHEMA
(There's no actual functionality gain here, but formerly you had to say
ALTER TABLE instead.)

Interestingly, the grammar tables actually get smaller, probably because
there are fewer special cases to keep track of.

I did not disallow using ALTER TABLE for these operations.  Perhaps we
should, but there's a backwards-compatibility issue if we do; in fact
it would break existing pg_dump scripts.  I did however tighten up
ALTER SEQUENCE and ALTER VIEW to reject non-sequences and non-views
in the new cases as well as a couple of cases where they didn't before.

The patch doesn't change pg_dump to use the new syntaxes, either.

expand the pattern specifier.

Per gripe from Josh Drake.

objects are specified, we drop them all in a single performMultipleDeletions
call.  This makes the RESTRICT/CASCADE checks more relaxed: it's not counted
as a cascade if one of the later objects has a dependency on an earlier one.
NOTICE messages about such cases go away, too.

In passing, fix the permissions check for DROP CONVERSION, which for some
reason was never made role-aware, and omitted the namespace-owner exemption
too.

Alex Hunsaker, with further fiddling by me.

> 	o Add functions to syntax check configuration files
>
< * Add pg_ctl option to do a syntax check of postgresql.conf

the problem happened in.  These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.

Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back.  Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.

< * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause
> * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause or
>   target list
>   http://archives.postgresql.org/pgsql-hackers/2008-06/msg00124.php

forks. XLogOpenRelation() and the associated light-weight relation cache in
xlogutils.c is gone, and XLogReadBuffer() now takes a RelFileNode as argument,
instead of Relation.

For functions that still need a Relation struct during WAL replay, there's a
new function called CreateFakeRelcacheEntry() that returns a fake entry like
XLogOpenRelation() used to.

devised for pg_shdepend, namely the individual dependencies are reported as
DETAIL lines rather than coming out as separate NOTICEs.  The client-side
report is capped at 100 lines, but the server log always gets a full report.