Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)
От | Andres Freund |
---|---|
Тема | Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc) |
Дата | |
Msg-id | 20160414222242.ec4m74aqsh4eshde@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)
|
Список | pgsql-bugs |
On 2016-04-14 15:14:37 -0400, Tom Lane wrote: > I've been looking around and testing some more. I noticed that the only > caller of ReorderBufferRestoreChange always passes a maxaligned buffer, > so most of the changes I suggested are unnecessary. AFAICT, it's only > the second fetch of t_len that is at any risk. I think so too. And I agree that a comment about this would have been rather helpful... > Even there, at least in > HEAD, I cannot construct a test case in which the first tuple's t_len is > not a multiple of 4. That's really kinda weird. It's a tuple from WAL, and the length's from the record; the same way wal replay gets it. Wonder if this might not indicate a relevant bug somewhere... > I have a suspicion that > something in the impenetrable thicket that passes for prefix/suffix > optimization in log_heap_update is forcing the WAL-logged tuple length to > be rounded off to sizeof(int) (*not* MAXALIGN). I don't think so, because the prefix optimization is essentially disabled for logical... > So I now think my previous patch is overkill, and we should instead use > something like the attached. Looks good to me. Thanks! - Andres
В списке pgsql-bugs по дате отправления: