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