On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
