| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bridget Frey <bridget(dot)frey(at)redfin(dot)com>, Michael Brauwerman <michael(dot)brauwerman(at)redfin(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #6200: standby bad memory allocations on SELECT |
| Date: | 2012-01-31 21:25:29 |
| Message-ID: | 10830.1328045129@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?
Well, I was kinda speculating that inadequate locking could result in
use of a stale (or too-new?) tuple descriptor, and that would be as good
a candidate as any if the basic theory were right. But Bridget says
they are not doing any DDL, so it's hard to see how there'd be any tuple
descriptor mismatch at all. Still baffled ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-01-31 21:37:11 | Re: inet subtraction fails with IPv6? |
| Previous Message | Jon Nelson | 2012-01-31 20:07:59 | Re: inet subtraction fails with IPv6? |