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 по дате отправления: