now".  This can happen if the time granularity is not very high.

Per ITAGAKI Takahiro.

non-standard way of indicating errors, so we don't try to
allocate INT_MAX bytes to store a result in.

< Last updated:		Sat May  5 10:47:39 EDT 2007
> Last updated:		Sat May  5 11:39:57 EDT 2007
< * Flush cached query plans when the dependent objects change,
<   when the cardinality of parameters changes dramatically, or
> * -Flush cached query plans when the dependent objects change or
<
<   A more complex solution would be to save multiple plans for different
<   cardinality and use the appropriate plan based on the EXECUTE values.
<
< * Track dependencies in function bodies and recompile/invalidate
<
<   This is particularly important for references to temporary tables
<   in PL/PgSQL because PL/PgSQL caches query plans.  The only workaround
<   in PL/PgSQL is to use EXECUTE.  One complexity is that a function
<   might itself drop and recreate dependent tables, causing it to
<   invalidate its own query plan.
<
< * Invalidate prepared queries, like INSERT, when the table definition
> * -Track dependencies in function bodies and recompile/invalidate
> * -Invalidate prepared queries, like INSERT, when the table definition

< * Invalidate prepared queries, like INSERT, when the table definition
<   is altered
>
> * Invalidate prepared queries, like INSERT, when the table definition
>   is altered

> 	o -Allow multiple vacuums so large tables do not starve small

> * -Allow ORDER BY ... LIMIT # to select high/low value without sort or
<
<   Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
<   all values to return the high/low value.  Instead The idea is to do a
<   sequential scan to find the high/low value, thus avoiding the sort.
<   MIN/MAX already does this, but not for LIMIT > 1.
<

actual sort strategy and amount of space used.  By popular demand.

Make clearer how arguments and return values in pl/perl are escaped. This is to clarify the situation that Theo Schlossnagle recently reported on -bugs.

and for other compilers, insert a dummy exit() call so that they understand
PG_RE_THROW() doesn't return.  Insert fflush(stderr) in ExceptionalCondition,
per recent buildfarm evidence that that might not happen automatically on some
platforms.  And const-ify ExceptionalCondition's declaration while at it.

need be returned.  We keep a heap of the current best N tuples and sift-up
new tuples into it as we scan the input.  For M input tuples this means
only about M*log(N) comparisons instead of M*log(M), not to mention a lot
less workspace when N is small --- avoiding spill-to-disk for large M
is actually the most attractive thing about it.  Patch includes planner
and executor support for invoking this facility in ORDER BY ... LIMIT
queries.  Greg Stark, with some editorialization by moi.

pages it intends to zero immediately.  Just to show there is some use for that
function besides WAL recovery :-).
Along the way, fold _hash_checkpage and _hash_pageinit calls into _hash_getbuf
and friends, instead of expecting callers to do that separately.

the relevant fixes to 8.2 as well.

for local symbols, that shouldn't be exported. This patch excludes them,
cutting down about 10,000 exported symbols and decreasing the binary size
by 20%.

ReadOrZeroBuffer to fetch pages from beyond physical EOF.  This would
usually work, but would cause problems for md.c if writes occurred
beyond a segment boundary when the previous segment file hadn't been
fully extended.

from the WAL data, don't bother to physically read it; just have bufmgr.c
return a zeroed-out buffer instead.  This speeds recovery significantly,
and also avoids unnecessary failures when a page-to-be-overwritten has corrupt
page headers on disk.  This replaces a former kluge that accomplished the
latter by pretending zero_damaged_pages was always ON during WAL recovery;
which was OK when the kluge was put in, but is unsafe when restoring a WAL
log that was written with full_page_writes off.

Heikki Linnakangas

true at the very end of its processing, the update is broadcast via a
shared-cache-inval message for the index; without this, existing backends that
already have relcache entries for the index might never see it become valid.
Also, force a relcache inval on the index's parent table at the same time,
so that any cached plans for that table are re-planned; this ensures that
the newly valid index will be used if appropriate.  Aside from making
C.I.C. behave more reasonably, this is necessary infrastructure for some
aspects of the HOT patch.  Pavan Deolasee, with a little further stuff from
me.

and TimestampDifference, to make coding clearer.  I think this should also fix
the failure to start workers in platforms with low resolution timers, as
reported by Itagaki Takahiro.

could happen when a worker took to long to start and was thus "aborted" by the
launcher.  Noticed by lionfish buildfarm member.

isn't any place to throw the error to.  If so, we should treat the error
as FATAL, just as we would have if it'd been thrown outside the PG_TRY
block to begin with.

Although this is clearly a *potential* source of bugs, it is not clear
at the moment whether it is an *actual* source of bugs; there may not
presently be any PG_TRY blocks in code that can be reached with no outer
longjmp catcher.  So for the moment I'm going to be conservative and not
back-patch this.  The change breaks ABI for users of PG_RE_THROW and hence
might create compatibility problems for loadable modules, so we should not
put it into released branches without proof that it's needed.

the install.

Dave Page

wrong thing when inlining polymorphic SQL functions, because it was using the
function's declared return type where it should have used the actual result
type of the current call.  In 8.1 and 8.2 this causes obvious failures even if
you don't have assertions turned on; in 8.0 and 7.4 it would only be a problem
if the inlined expression were used as an input to a function that did
run-time type determination on its inputs.  Add a regression test, since this
is evidently an under-tested area.

from time_t to TimestampTz representation.  This provides full gettimeofday()
resolution of the timestamps, which might be useful when attempting to
do point-in-time recovery --- previously it was not possible to specify
the stop point with sub-second resolution.  But mostly this is to get
rid of TimestampTz-to-time_t conversion overhead during commit.  Per my
proposal of a day or two back.

still be forced out at backend exit.

messages to the stats collector.  This avoids the problem that enabling
stats_row_level for autovacuum has a significant overhead for short
read-only transactions, as noted by Arjen van der Meijden.  We can avoid
an extra gettimeofday call by piggybacking on the one done for WAL-logging
xact commit or abort (although that doesn't help read-only transactions,
since they don't WAL-log anything).

In my proposal for this, I noted that we could change the WAL log entries
for commit/abort to record full TimestampTz precision, instead of only
time_t as at present.  That's not done in this patch, but will be committed
separately.

to copy nodes that are known to be Vars during plan reference adjustment.
Saves useless memzero operation as well as the big switch in copyObject.

We can just palloc, instead of using makeNode, when we are going to
overwrite the whole node anyway in the FLATCOPY macro.  Also, use
FLATCOPY instead of copyObject for common node types Var and Const.

look through a freelist for a chunk of adequate size.  For a long time
now, all elements of a given freelist have been exactly the same
allocated size, so we don't need a loop.  Since the loop never iterated
more than once, you'd think this wouldn't matter much, but it makes a
noticeable savings in a simple test --- perhaps because the compiler
isn't optimizing on a mistaken assumption that the loop would repeat.
AllocSetAlloc is called often enough that saving even a couple of
instructions is worthwhile.

< * Make standard_conforming_strings the default in 8.3?
> * Make standard_conforming_strings the default in 8.4?

< 		o Add support for MOVE and SCROLL cursors
<
< 		  PL/pgSQL cursors should support the same syntax as
< 		  backend cursors.
<
> 		o -Add support for MOVE cursors
> 		o Add support for SCROLL cursors

by Pavel Stehule, and reviewed by Neil Conway.

for consistency with the backend's FETCH command. Patch from Pavel
Stehule, reviewed by Neil Conway.