Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date
Msg-id 13230.943860793@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
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.

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...

            regards, tom lane

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions