Re: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

On Wed, Mar 08, 2000 at 03:41:17AM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Bruce seems to be willing to accept a window of failure for RENAME
> >> TABLE in order to make database admin easier.  That is very possibly
> >> the right tradeoff --- but it is *not* an open-and-shut decision.
> >> We need to talk about it.
> 
> > How about creating a hard link during RENAME, and you can just remove
> > the old link on commit or remove the new link on transaction rollback?
> 
> Still non-atomic as far as I can see...
> 

And there doesn't seem to be an obvious way to extend it to the DROP
TABLE case. Hmm, on second thought, to rollback DROP TABLE we'll need to
'hide' the table from the current transaction: one way would be to rename
it, then do the drop at commit time.

Regardless, since I think there are other, SQL92 standard driven reasons to
break the relname == filename link, I decided to go ahead and see how hard
coding it would be, and how much code might be depending on that behavior.

Looked like it was going to be very simple: the RelationGetRelationName
and RelationGetPhysicalRelationName macros encapsulate access to the
(relation)->rd_rel->relname structure member pretty effectively (thanks
to Bruce's temp. relation work, I presume)

As a first crack, I decided to use the oid for the filename, just because
it simplified the chamges to the Macro, and there was already an oidout()
builtin that'd do the palloc for me ;-)

<some time latter...>

Well, ... it is, as they say, a Small Matter of Programming. I now know
a lot more about the bootstrap process, and the relcache, I can tell you!

Most problems where code that used RelationGetPhysicalRelationName
when they it should use RelationGetRelationName. In several cases,
the code assumed RelationGetPhysicalRelationName handed them a
pointer to rd_rel->relname, which they copy into! I substituted
RelationGetRelationName for all these cases.

There's some uglyness with SharedSystemRelations, as well. I just hacked
in hard coded numbers where ever I found hardcoded relation names, for
an inital test of principle.

I've got a version running, and I can type at a standalone backend:
still some problems with initdb: the pg_log, pg_shadow and pg_user
relations don't get created: I cheated and copied the first two from my
'current' install. That got the backend up, either standalone, or as
postmaster. It'll even accept connections from pgsql: just errors a lot,
since pg_user isn't there!

However, typing at the backend, I can create tables, insert, delete,
start transactions, rollback, etc. Basically, everything works.

Suffice to say, altering the physical storage name is not too difficult,
if _I_ can get this far in just a few hours. Whatever we decide for
'policy' on the name issue (and now that I've generated it, I can tell
you that a directory full of numbers is _really_ ugly) implementation
should go easily.


Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005