Skip site navigation (1) Skip section navigation (2)

Re: Proposal for DROP TABLE rollback mechanism

From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for DROP TABLE rollback mechanism
Date: 2000-10-28 18:40:19
Message-ID: 007901c0410e$86947e00$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > 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.


In response to


pgsql-hackers by date

Next:From: Kevin O'GormanDate: 2000-10-28 18:48:14
Subject: Re: syntax
Previous:From: The Hermit HackerDate: 2000-10-28 18:17:38
Subject: Re: Gram.y patches for better parenthesis handling.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group