Re: Proposal for DROP TABLE rollback mechanism

"Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> writes:
> BTW, why do we force buffers to disk in FlushRelationBuffers at all?
> Seems all what is required is to flush them *from* pool, not *to* disk
> immediately.

Good point. Seems like it'd be sufficient to do a standard async write
rather than write + fsync.

We'd still need some additional logic at commit time, however, because
we want to make sure there are no BufferDirtiedByMe bits set for the
file we're about to delete...

>> Also, I don't feel comfortable with the idea of doing
>> FlushRelationBuffers mid-transaction and then relying on the buffer
>> cache to still be empty of pages for that relation much later on when
>> we finally commit. Sure, it *should* be empty, but I'll be happier
>> if we flush the buffer cache immediately before deleting the file.

> (It *must* be empty -:)

In the absence of bugs, yes, it must be empty for the case where we
are committing a DROP. But I want a safety check to catch those bugs.
Besides, what of the case where we are aborting a CREATE? There must be
a bufmgr call that will allow us to ensure there are no buffers left for
the relation we intend to delete.

How about this: change FlushRelationBuffers so that it does standard
async writes for dirty buffers and then removes all the rel's buffers
from the pool. This is invoked inside the transaction, same as now.
Make DROP TABLE call this routine, *not* RemoveRelationBuffers.
Then call RemoveRelationBuffers from smgr during transaction commit or
abort. In the commit case, there really shouldn't be any buffers for
the rel, so we can emit an elog NOTICE (it's too late for ERROR, no?)
if we find any. But in the abort case, we'd not be surprised to find
buffers, even dirty buffers, and we just want to throw 'em away. This
would also be the place to clean out the BufferDirtiedByMe state.

If you don't like the smgr->bufmgr call, the reason for that is we're
asking smgr to keep the list of pending relation deletes. We could make
a new module, logically above smgr and bufmgr, to keep that list
instead. But I don't think it's worth the trouble.

> Please note that there is xlog_bufmgr.c If you'll add/change something in
> bufmgr please let me know later.

Will keep you informed.

regards, tom lane