Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Date: 2016-05-16 16:44:07
Message-ID: CAMkU=1zK+yBOChgk3HSRtQX6LxOeNXpP7onSo4GkOd4a01jk-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 16, 2016 at 8:28 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-05-10 17:58:33 -0700, Andres Freund wrote:
>> FWIW, I've commented out the relevant sections from xlog_redo and since
>> then I've not been able to reproduce the issue.
>
> A couple days of running later, and it hasn't yet re-triggered. So I
> assume that's indeed the fix.

Yes, I've also run it to wrap-around a few times with that commented
out, so I agree that that is a fix. But I don't think we should apply
until we get the larger issue with hit-bits is fixed first, as then we
are masking one problem by fixing another.

Although it doesn't really matter to me, because I'm not using HEAD to
run the tests anyway, as I can't get the error to trigger on HEAD. As
a side note, using 48354581a49c30f5 and without commenting out the
part of the replay code we are talking about, I also need
track_io_timing to be on in order to get the error. I don't think
there is any direct causation there, just another fiddly timing issue.

I've tried fixing the hit-bit issue as well, but I'm afraid it is over
my head. I'll be happy to test proposed patches, though.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2016-05-16 17:59:04 Re: 10.0
Previous Message Robert Haas 2016-05-16 16:37:32 trivia: cancel{,l}{ed,ing,ation}