Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)

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