Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Дата | |
Msg-id | 384232AC.C546A8C0@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Список | pgsql-hackers |
Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> I have to say that I'm going to change on-disk database/table/index > >> file names to _OID_! This is required by WAL because of inside of > >> log records there will be just database/table/index oids, not names, > >> and after crash recovery will not be able to read pg_class to get > >> database/table/index name using oid ... > > > Wow, that is a major pain. Anyone else think so? > > Using oid's instead of names may give us some ability to fix some other > > bugs, though. > > Yes, and yes. I've been trying to nerve myself to propose that, because > it seems the only reasonable way to make rollback of RENAME TABLE and > DROP TABLE work safely. It'll be a pain in the neck for debugging and > admin purposes though. So, no more nerves needed, Tom, yeh? -:) It would be nice if someone else, not me, implement this... > Can we make some sort of usually-correct-but-not-guaranteed-correct > dump that shows which corresponds to what? Maybe something similar > to the textfile dump of pg_shadow that the postmaster uses for password > authentication? Then at least you'd have some shot at figuring out > which file was what in extremis... As it was proposed - utility to create dir with database name (in addition to dir with database oid where data really live) and symlinks there: table_name --> ../db_oid/table_oid Vadim
В списке pgsql-hackers по дате отправления: