and int2vector.

properly.

Improve cache invalidation handling. Eespecially
this would fix TODO
* elog() flushes cache, try invalidating just entries from
  current xact, perhaps using invalidation cache

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.

specified by regular-expression patterns.  Add some more files.

remove the no-longer-used files.

traced this back to what I believe is an error in the sgml file used to
generate this comment, found in pgsql/doc/src/sgml/ref/alter_table.sgml.


Stephen Birch

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.

Do not start postmaster if postgres is running

Instead of hard-wiring one result file per platform, there is a map file
'resultmap' that says which one to use --- a lot like template/.similar.
I have only created entries in resultmap for my own platform (HPUX) so
far; feel free to add lines for other platforms.

Note: don't put any of these back till you've grokked the new code for
platform-specific comparisons that I'm about to commit...

them --- it is just *way* too painful to keep expected results in sync
when these are present.

which is broken in some weird way that I don't understand.  I think it
may be exposing a bug in the new psql --- for one thing, I get different
results when I run psql by hand than the regress script gets.  What
the heck???

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