Re: BUG #6200: standby bad memory allocations on SELECT

On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Hm.  The stack trace is definitive that it's finding the bad data in a
>> tuple that it's trying to print to the client, not in an index.
>
> BTW, after a bit more reflection it occurs to me that it's not so much
> that the data is necessarily *bad*, as that it seemingly doesn't match
> the tuple descriptor that the backend's trying to interpret it with.

Hmm. Could this be caused by the recovery process failing to obtain a
sufficiently strong lock on a buffer before replaying some WAL record?
For example, getting only an exclusive content lock where a cleanup
lock is needed could presumably cause something like this to happen -
it would explain the transient nature of the errors as well as the
fact that they only seem to occur during Hot Standby operation. On
the other hand, it's a little hard to believe we would have missed
something that obvious; there aren't that many things that need a
cleanup lock on a heap page.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company