Re: [HACKERS] Happy column dropping

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chris(at)bitmead(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Happy column dropping
Date: 2000-01-25 03:18:29
Message-ID: 11344.948770309@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Bitmead <chris(at)bitmead(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-01-25 03:22:44 RE: [HACKERS] Happy column dropping
Previous Message Chris Bitmead 2000-01-25 03:09:50 Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace