> I think the problem is that BufferSync unconditionally does PinBuffer
> on each buffer, and holds the pin during intervals where it's released
> BufMgrLock, even if there's not really anything for it to do on that
> buffer.  If someone else is running FlushRelationBuffers then it's
> possible for that routine to see a nonzero pin count when it looks.
> 
> Vadim, what do you think about how to change this?  I think this is
> BufferSync's fault not FlushRelationBuffers's ...

I'm looking there right now...

Vadim

Tue, 20 Mar 2001 16:44:17 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Beta 6 Regression results on Redat 7.0. 
>> I think the problem is that BufferSync unconditionally does PinBuffer
>> on each buffer, and holds the pin during intervals where it's released
>> BufMgrLock, even if there's not really anything for it to do on that
>> buffer.  If someone else is running FlushRelationBuffers then it's
>> possible for that routine to see a nonzero pin count when it looks.

Further note: this bug does not arise in 7.0.* because in that code,
BufferSync will only pin buffers that have been dirtied in the current
transaction.  This cannot affect a concurrent FlushRelationBuffers,
which should be holding exclusive lock on the table it's flushing.

Or can it?  The above is safe enough for user tables, but on system
tables we have a bad habit of releasing locks early.  It seems possible
that a VACUUM on a system table might see pins due to BufferSyncs
running in concurrent transactions that have altered that system table.

Perhaps this issue does explain some of the reports of
FlushRelationBuffers failure that we've seen from the field.

			regards, tom lane

Tue, 20 Mar 2001 20:07:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Beta 6 Regression results on Redat 7.0. 