- 23 Sep, 1999 8 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
This is because (-1) << 32 is -1 (Only intel arc. has been checked) Oleg Sharoiko
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 21 Sep, 1999 7 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
libpq++. Patrick Welche
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 20 Sep, 1999 11 commits
-
-
Marc G. Fournier authored
last batch, I think...
-
Marc G. Fournier authored
fixing it more..
-
Marc G. Fournier authored
bring it all into -current again
-
Marc G. Fournier authored
try and fix things...
-
Marc G. Fournier authored
bring in missing files ... this isn't very clean, but :(
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 19 Sep, 1999 1 commit
-
-
Tom Lane authored
INSERT ... DEFAULT VALUES statement does indeed have a null targetlist, at least during parse and rewrite stages.
-
- 18 Sep, 1999 4 commits
-
-
Tom Lane authored
treat a NULL condition result as FALSE. Clean up some bogus comments here and there, too.
-
Tom Lane authored
error message wording, due to most cases of no-such-relation now being detected in central heap_open code rather than on an ad-hoc basis.
-
Tom Lane authored
additional argument specifying the kind of lock to acquire/release (or 'NoLock' to do no lock processing). Ensure that all relations are locked with some appropriate lock level before being examined --- this ensures that relevant shared-inval messages have been processed and should prevent problems caused by concurrent VACUUM. Fix several bugs having to do with mismatched increment/decrement of relation ref count and mismatched heap_open/close (which amounts to the same thing). A bogus ref count on a relation doesn't matter much *unless* a SI Inval message happens to arrive at the wrong time, which is probably why we got away with this sloppiness for so long. Repair missing grab of AccessExclusiveLock in DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi. Recommend 'make clean all' after pulling this update; I modified the Relation struct layout slightly. Will post further discussion to pghackers list shortly.
-
Bruce Momjian authored
-
- 17 Sep, 1999 4 commits
-
-
Michael Meskes authored
-
Bruce Momjian authored
-
Michael Meskes authored
-
Bruce Momjian authored
-
- 16 Sep, 1999 1 commit
-
-
Tatsuo Ishii authored
See attached mail for more details. ------------------------------------------------------------------- From: "Vadim Mikheev" <vadim@krs.ru> To: "Hiroshi Inoue" <Inoue@tpf.co.jp> References: <000201befa94$42fe04c0$2801007e@cadzone.tpf.co.jp> Subject: Re: elog(ERROR) in vacuum Date: Fri, 10 Sep 1999 10:27:10 +0900 Organization: OJSC Rostelecom (Krasnoyarsk) Message-ID: <37D85E6E.5AFA126D@krs.ru> Hiroshi Inoue wrote: > > Hello Vadim, > > I have a question about vacuum. > > VACUUM has a phase like commit which calls TransactionIdCommit(). > But if elog(ERROR) occured after that,the status of transaction is > changed from XID_COMMIT to XID_ABORT. > > Seems to me this causes inconsistency. > Shoudn't AbortTransaction() be changed not to call TransacionIdAbort() > in case of vacuum. You're right! As usual -:) Vadim
-
- 15 Sep, 1999 4 commits
-
-
Peter Mount authored
-
Peter Mount authored
into it.
-
Peter Mount authored
to version 2, and fixes ResultSetMetaData.getColumnDisplaySize().
-
Michael Meskes authored
-