Re: Proposal for DROP TABLE rollback mechanism

> > 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...

Note that there is no BufferDirtiedByMe in WAL bufmgr version.

> How about this: change FlushRelationBuffers so that it does standard
> async writes for dirty buffers and then removes all the rel's buffers

^^^^^^^^^^^^^^^^^^^^^^^^^
When it's used from vacuum no reason to do this.

> 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?)

^^^^^^^^^^^^^^^^^^^^^
Sure, but good time for Assert -:)

> 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.

BTW, currently smgrcommit is called twice on commit *before* xact
status in pg_log updated and so you can't use it to remove files. In
WAL version smgrcommit isn't called at all now but we easy can
add smgrcommit call after commit record is logged.

Vadim