Re: [HACKERS] Happy column dropping - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Happy column dropping
Date
Msg-id 11344.948770309@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Happy column dropping  (Chris Bitmead <chris@bitmead.com>)
List pgsql-hackers
Chris Bitmead <chris@bitmead.com> writes:
> Tom Lane wrote:
>> I was thinking about adding a "version number" to the pg_class entry
>> for a relation, and then having its actual filename look like

> Well, if you are going to re-write the files in place on update, a
> version  number seems like overkill. All you need is version "a" and
> "b". Every time you do a change it swaps from version RELATIONOID_a to
> RELATIONOID_b ,

And what happens when I do two (or more) DROP COLUMNs within a single
transaction?  Nope, you need an open-ended counter.

> ... Or you could just go
> for RELATIONOID and RELATIONOID_new and do a rename (although I guess
> you're trying to avoid that).

Precisely.  If we can avoid renaming the files, then we aren't at the
mercy of the OS while moving from "uncommitted" to "committed" state;
the only thing that matters is marking the transaction committed in
pg_log, and that's as atomic as we can make it.

If there's no rename, the worst that can happen is that no-longer-needed
files get left around (if the backend dies between committing and
removing dead files, or if it dies after making the files but before
committing the transaction).  We could arrange for VACUUM to remove such
files.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Happy column dropping
Next
From: Mike Mascari
Date:
Subject: Re: [HACKERS] Happy column dropping