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 | 20160413161906.aykti6iwdc7zv7l6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Bus error in pg_logical_slot_get_changes (9.4.7, sparc) (Christoph Berg <christoph.berg@credativ.de>) |
Ответы |
Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)
Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc) |
Список | pgsql-bugs |
Hi, On 2016-04-13 11:41:17 +0200, Christoph Berg wrote: > I've just uploaded 9.4.7 for Debian's wheezy-backports suite. > Unfortunately it's now crashing twice in the contrib/test_decoding > regression tests on sparc. I could reproduce the error on the porter > box: > > LOG: server process (PID 22534) was terminated by signal 10: Bus error > DETAIL: Failed process was running: SELECT data > FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1') > WHERE data ~ 'UPDATE'; > > LOG: server process (PID 22558) was terminated by signal 10: Bus error > DETAIL: Failed process was running: SELECT substr(data, 1, 200) FROM pg_logical_slot_get_changes('regression_slot', NULL,NULL, 'include-xids', '0', 'skip-empty-xacts', '1'); > > > Reading symbols from /home/myon/postgresql-9.4-9.4.7/build/src/backend/postgres...done. > [New LWP 22558] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1". > Core was generated by `postgres: myon regression [local] SELECT '. > Program terminated with signal 10, Bus error. > #0 ReorderBufferRestoreChange (data=0x5de0f7 "", txn=0x622660, rb=0x6225d8) > at /home/myon/postgresql-9.4-9.4.7/build/../src/backend/replication/logical/reorderbuffer.c:2327 > 2327 Size tuplelen = ((HeapTuple) data)->t_len; > (gdb) l > 2322 data += tuplelen; > 2323 } > 2324 > 2325 if (change->data.tp.newtuple) > 2326 { > 2327 Size tuplelen = ((HeapTuple) data)->t_len; Hrmpf, I guess this is an alignment issue. We should probably replace that ->t_len lookup with a memcpy. IIRC it's not entirely trivial to access porter boxes anymore - could you perhaps just replace those two t_len lookups with a memcpy (i.e. memcpy(&tuplelen, &(HeapTuple) data)->t_len, sizeof(uint32))? Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: