Re: Proposal for DROP TABLE rollback mechanism

"Vadim Mikheev" <vmikheev@sectorbase.com> writes:
> Please note that there is xlog_bufmgr.c If you'll add/change something in
> bufmgr please let me know later.

Per your request: I've changed bufmgr.c.  I think I made appropriate
changes in xlog_bufmgr, but please check.  The changes were:

1. Modify FlushRelationBuffers to do plain write, not flush (no fsync)
of dirty buffers.  This was per your suggestion.  FlushBuffer() now
takes an extra parameter indicating whether fsync is wanted.  I think
this change does not affect xlog_bufmgr at all.

2. Rename ReleaseRelationBuffers to DropRelationBuffers to make it more
clear what it's doing.

3. Add a DropRelFileNodeBuffers, which is just like DropRelationBuffers
except it takes a RelFileNode argument.  This is used by smgr to ensure
that the buffer cache is clear of buffers for a rel about to be deleted.

4. Update comments about usage of DropRelationBuffers and
FlushRelationBuffers. 

Rollback of DROP TABLE now works in non-WAL code, and seems to work in
WAL code too.  I did not add WAL logging, because I'm not quite sure
what to do, so rollforward probably does the wrong thing.  Could you
deal with that part?  smgr.c is the place that keeps the list of what
to delete at commit or abort.
        regards, tom lane