> > 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'Gorman||Date: 2000-10-28 18:48:14|
|Subject: Re: syntax|
|Previous:||From: The Hermit Hacker||Date: 2000-10-28 18:17:38|
|Subject: Re: Gram.y patches for better parenthesis handling.|