Re: BUG #14295: Hot standby crash during tsvector rebuild
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #14295: Hot standby crash during tsvector rebuild |
| Дата | |
| Msg-id | 8020.1472916375@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #14295: Hot standby crash during tsvector rebuild (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #14295: Hot standby crash during tsvector rebuild
|
| Список | pgsql-bugs |
I wrote:
> Spencer Thomason <spencer@whiteskycommunications.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
В списке pgsql-bugs по дате отправления: