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