Re: [HACKERS] Happy column dropping

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Happy column dropping
Дата
Msg-id 11344.948770309@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Happy column dropping  (Chris Bitmead <chris@bitmead.com>)
Список 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 по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Happy column dropping
Следующее
От: Mike Mascari
Дата:
Сообщение: Re: [HACKERS] Happy column dropping