Re: BUG #14295: Hot standby crash during tsvector rebuild

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

In response to

Responses

Browse pgsql-bugs by date

  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