RE: Beta 6 Regression results on Redat 7.0.

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

Another possible source of this problem (in 7.0.X) is BufferReplace..?

Vadim