From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) |
Date: | 2002-04-14 18:13:21 |
Message-ID: | 22678.1018808001@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> No, VACUUM has the same transactional constraints as everyone else
>> (unless you'd like a crash during VACUUM to trash your table...)
> Seriously, you can run VACUUM in a transaction and rollback the movement of
> a tuple on disk? What do you mean by same transactional constraints?
In VACUUM FULL, tuples moved to compact the table aren't good until you
commit. In this hypothetical column-drop-implementing VACUUM, I think
there'd need to be some similar rule --- otherwise it's not clear what
happens to TOASTED data if you crash partway through. (In particular,
if we tried overwriting main tuples in place as Hannu was suggesting,
we'd need a way of being certain the deletion of the corresponding TOAST
rows occurs *before* we overwrite the only reference to them.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2002-04-14 18:35:13 | Redhat 7.2.93 performance (was:Re: PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC) |
Previous Message | Peter Eisentraut | 2002-04-14 17:46:39 | Re: [PATCHES] WITH DELIMITERS in COPY |