From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue) |
Date: | 2000-05-19 03:31:34 |
Message-ID: | 6149.958707094@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I was about to change FlushRelationBuffers anyway to get rid of
>> the bogus warning message. What I propose to do is give it two
>> behaviors:
>> (1) write out dirty buffers at or beyond the specified block,
>> but don't remove buffers from pool; or
>> (2) remove buffers at or beyond the specified block from pool,
>> after writing them out if dirty.
>>
>> VACUUM should apply case (2) beginning at the proposed truncation point,
>> and then apply case (1) starting at block 0.
>>
>> Sound good?
> Agreed.
OK, I've committed a fix for this. After looking at the uses of
FlushRelationBuffers, I gave it just one behavior: flush *all* dirty
buffers of the relation, and remove from the cache those that are
at or beyond the specified block number. This allows VACUUM's needs
to be met in one buffer-cache scan instead of two.
I also cleaned up ReleaseRelationBuffers, which should have but did
not remove the relation's buffers from the cache. This left us with
"valid" buffers for a deleted relation after any DROP TABLE. No
known bug there, but clearly trouble waiting to happen. Likewise
for DropBuffers (same thing for a whole database).
Finally, the "removal" of the deleted buffers in these routines
consisted of calling BufTableDelete(), which removes the buffer from the
shared-buffer hashtable, so it will not be found by a lookup for a
specific block --- but the various routines that scan the whole
shared-buffer array would still think the buffer belongs to its former
relation! That can't be good either, so I made BufTableDelete() clear
the tag field for the buffer.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-19 03:38:19 | Re: [SQL] Foreign keys breaks tables permissions |
Previous Message | Stephan Szabo | 2000-05-19 02:58:32 | Re: [SQL] Foreign keys breaks tables permissions |