Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Mar 9, 2017 at 9:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Buildfarm thinks eight wasn't enough.
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clam&dt=2017-03-10%2002%3A00%3A01
> At first I was confused how you knew that this was the fault of this
> patch, but this seems like a pretty indicator:
> TRAP: FailedAssertion("!(curval == 0 || (curval == 0x03 && status !=
> 0x00) || curval == status)", File: "clog.c", Line: 574)
Yeah, that's what led me to blame the clog-group-update patch.
> I'm not sure whether it's related to this problem or not, but now that
> I look at it, this (preexisting) comment looks like entirely wishful
> thinking:
> * If we update more than one xid on this page while it is being written
> * out, we might find that some of the bits go to disk and others don't.
> * If we are updating commits on the page with the top-level xid that
> * could break atomicity, so we subcommit the subxids first before we mark
> * the top-level commit.
Maybe, but that comment dates to 2008 according to git, and clam has
been, er, happy as a clam up to now. My money is on a newly-introduced
memory-access-ordering bug.
Also, I see clam reported in green just now, so it's not 100%
reproducible :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
