> > 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.
I look at this and question the value of allowing such fancy things vs.
the ability to look at the directory and know exactly what table is
which file. Maybe we can use file names like 23423_mytable where 24323
is the table oid and mytable is the table name. That way, we can know
the table, and they are unique too to allow RENAME TABLE to work.
This doesn't solve Vadim's problem. His additional work would be to
write a line to the log file for each table create/delete saying I
deleted this table with this oid, and when reading back the log, he has
to record the oid_username combination and use that to translate his log
oids into actual filenames.
In fact, doesn't that information already appear in the WAL log as part
of pg_class changes? Or is the problem that the table changes happen
before the pg_class is committed?
> 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...
That is OK, and a possible workaround if the above idea is not good.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026