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 по дате отправления: