Cygwin snapshots (tested on 990115 which is recommended to use - it fixes
some errors in B20.1)
And I have another patch for including <sys/ipc.h> before <sys/sem.h> in
backend/storage/lmgr/proc.c - it is required due the design of cygipc
headers
Dan
One last missing quoting bug in pg_dump:
now that sequence names are properly quoted for field defaults, mixed
case sequence names are generated. These are properly quoted in the
CREATE SEQUENCE lines, but not in the SELECT nextval lines, as per
below:
CREATE SEQUENCE "Teams_TeamID_seq" start 10 increment 1 maxvalue
2147483647 minvalue 1 cache 1 ;
SELECT nextval ('Teams_TeamID_seq');
This needs to be:
SELECT nextval ('"Teams_TeamID_seq"');
Patch included below.
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
from the configuration symbols, but neglected to remove #ifdef HAVE_KILL
from async.c in the REL6_5 branch. Result: cross-backend NOTIFY dead in
the water.
Almost worked before, but forgot one place to check.
Reported by Tatsuo Ishii.
Still does not do the right thing if inserting into a non-string target
column. Should look for a type coersion later, but doesn't.
transaction abort --- before it only worked if there was exactly one level
of allocation context stacked in the blank portal. Now it does the right
thing for any depth, including zero...
This is unsafe in 6.5 because other backends may be able to access the file
before noticing the shared cache inval message that tells 'em to re-open
the file. We have fixed this for 6.6 but the changes seem too risky to
back-patch for 6.5.2.
Also, back-patch Tatsuo's change to prevent creation of files during
mdopen().
I believe this is a pretty critical bugfix, since without it, stored rules
containing CASE expressions or array references cannot be dumped by pg_dump.
Worse, rules containing expressions like (a + b) * c will be dumped
incorrectly (minus the parentheses, silently yielding the wrong answer...).
I believe this is not a violation of our policy against requiring initdb
for minor-version bugfixes, since users don't *have* to initdb; they
just won't see any effect from the fix if they don't. But a user who
does do a clean install or initdb upgrade to 6.5.2 will get the fix,
and that seems worthwhile.
It will keep track the number of pages allocated so that
vacuum could allocate twice of the previous allocation.
This will greatly reduce the total memory consumption of
vacuum.
-------
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
I didn't see any further discussion so here is, I hope, a clean fix to
configure.in to determine if a system is ELF or not. Note that some
of the tests earlier may be redundant but I took the safest route.
