From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Spencer Thomason <spencer(at)whiteskycommunications(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14295: Hot standby crash during tsvector rebuild |
Date: | 2016-09-03 15:26:15 |
Message-ID: | 8020.1472916375@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Spencer Thomason <spencer(at)whiteskycommunications(dot)com> writes:
>> Also, I should note that this is on a SPARC T2 at 1.4GHz so the single thread performance might be a factor as well.
> Am I right in thinking that is a 32-bit machine? That might have
> something to do with it (notably because of different maxalign).
Awhile later it occurred to me that SPARCs are generally big-endian,
which led me to try your example on an old HPPA box, and kaboom!
I've now traced it to this bit in gindatapage.c:
int nmodifieditems;
...
memcpy(walbufend, &seginfo->nmodifieditems, sizeof(uint16));
which of course works fine on little-endian hardware and not at all on
big-endian. There might be more bugs (takes a while to run your example
on that old dinosaur :-() but this one is sufficient to explain the
known symptoms.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-03 15:49:57 | Re: BUG #14295: Hot standby crash during tsvector rebuild |
Previous Message | Spencer Thomason | 2016-09-03 15:19:26 | Re: BUG #14295: Hot standby crash during tsvector rebuild |