errors.  VACUUM normally compacts the table back-to-front, and stops
as soon as it gets to a page that it has moved some tuples onto.
(This logic doesn't make for a complete packing of the table, but it
should be pretty close.)  But the way it was checking whether it had
got to a page with some moved-in tuples was to look at whether the
current page was the same as the last page of the list of pages that
have enough free space to be move-in targets.  And there was other
code that would remove pages from that list once they got full.
There was a kluge that prevented the last list entry from being
removed, but it didn't get the job done.  Fixed by keeping a separate
variable that contains the largest block number into which a tuple
has been moved.  There's no longer any need to protect the last element
of the fraged_pages list.
Also, fix NOTICE messages to describe elapsed user/system CPU time
correctly.

postmaster/postmaster.c so that
tcop/postgres.c can use them. Now we have an interlock between
postmaster and postgres.

tcop/postgres.c can use them. Now we have an interlock between
postmaster and postgres.

code cleanup; no major improvements yet.  However, EXPLAIN does produce
more intuitive outputs for nested loops with indexscans now...

as well as when inserting entries into an existing index.

still
without answer. I want continue with to_char(), but I need any answer
for this patch. Please.

Thank! (and sorry of my impatient :-)
                                                        Karel

in trigger manager.

Jan

SET DEFAULT referential action triggers.

Jan

1) datetime_pl_span() added the seconds field before adding the months
 field.  This lead to erroneous results for e.g.
   select datetime '1999-11-30' + timespan '1 mon - 1 sec';
 Reverse the order of operations to add months first.
2) tm2timespan() did all intermediate math as integer, converting to double
 at the very end. This resulted in hidden overflows when given very large
 integer days, hours, etc. For example,
   select '74565 days'::timespan;
 produced the wrong result. Change code to ensure that doubles are used
 for intermediate calculations.
Thanks to Olivier PRENANT <ohp@pyrenet.fr> and
 Tulassay Zsolt <zsolt@tek.bke.hu> for problem reports and to Tom Lane for
 accurate analyses.

to be Y2K safe.

by continuing to increment the rightmost character until we get a string
that is demonstrably greater than the pattern prefix.

<= and >= indexquals from a LIKE even if the index in question didn't
support those operators.  (As, for example, a hash index does not.)

sequence doesn't exist.

during InitProcessingMode and the CurrentTransactionState was neither
TRANS_DEFAULT nor TRANS_DISABLED.  Unfortunately, after someone's recent
change to start the transaction manager earlier in startup than it used
to be started, that caused an abort() and consequent database system
reset on quite harmless errors (such as rejecting an invalid user name!).
As far as I can see, the test on CurrentTransactionState was completely
useless anyway, so I've removed it.

relcache entry no longer leaks a small amount of memory.  index_endscan
now releases all the memory acquired by index_beginscan, so callers of it
should NOT pfree the scan descriptor anymore.

by subselect used as expression."

Jan

not BLCKSZ/2 as some of us thought.  Add check for oversize item so that
failure is detected before corrupting the index, not after.

	SELECT null::text;
	SELECT int4fac(null);
work as expected now.  In some cases a NULL must be surrounded by
parentheses:
	SELECT 2 + null;                 fails
	SELECT 2 + (null);               OK
This is a grammatical ambiguity that seems difficult to avoid.  Other
than that, NULLs seem to behave about like you'd expect.  The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.

to live in a transaction before access to db
during backend startup.

Jan

with DEC C.

DEC C doesn't handle double values greater than DBL_MAX, but some
PostgreSQL geo functions assign greater than DBL_MAX values to some vars
in some special cases - that couses SIGFPE. I dunno if that is the only place
to fix to work well with DEC C.

Kirill Nosov.

in regression tests.

Jan

Jan

rather than returning a NaN for bogus input to pow().  Namely, HPUX 10.20.
I think this is sufficient evidence for what I thought all along, which
is that the float.c code *must* look at errno whether finite() exists or
not.

what a header file is for :-(

 Somehow got bracketed with #ifdef NOT_USED instead.

Jan