Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN (was RFC: Restructuring pg_aggregate)
Date
Msg-id 22678.1018808001@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN (was RFC: Restructuring pg_aggregate)  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] WITH DELIMITERS in COPY
Next
From: Lamar Owen
Date:
Subject: 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)