Re: Proposal for DROP TABLE rollback mechanism

> > Mmmm, why not call FlushRelationBuffers? Calling bufmgr from smgr
> > doesn't look like right thing. ?
>
> Yes, it's a little bit ugly, but if we call FlushRelationBuffers then we
> will likely be doing some useless writes (to flush out pages that we are
> only going to throw away anyway). If we leave the buffers alone till
> commit, then we'll only write out pages if we need to recycle a buffer
> for another use during that transaction.

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. In WAL bufmgr version (temporary in xlog_bufmgr.c)
I've changed this. Actually I wouldn't worry about these writes at all -
drop relation is rare case, - but ok.

> 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 -:) Sorry, I don't understand "*immediately* before"
in multi-user environment. Relation must be excl locked and this must
be only guarantee for us, not time of doing anything with this relation.)

> What might make sense is to make a pass over the buffer cache at the
> time of DROP (inside the transaction) to make sure there are no pinned
> buffers for the rel --- if so, we want to elog() during the transaction
> not after commit. We could also release any non-dirty buffers at
> that point. Then after commit we know we don't care about the dirty
> buffers anymore, so we come back and discard them.

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

Vadim