Hi,
Thanks for the report!
On 2016-01-22 15:45:27 +0300, Dmitriy Sarafannikov wrote:
> Hi, i'm trying to test logical decoding on server under load.
> I launched pg_recvlogical with 'test_decoding' plugin and wal sender was crashed with segfault after several minutes
ofwork.
>
> pg_recvlogical --start --slot test_slot --no-loop -d dbname -h 127.0.0.1 -p5432 -U dbuser -w -f
/tmp/test_logical.xlog
>
> postgres=# select version();
> version
> -----------------------------------------------------------------------------------------------
> PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
> (1 row) I have core dump file (size 66G)
>
> I launch gdb with core file and getting incomplete backtrace:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007fa9248af742 in ReorderBufferGetTupleBuf ()
> (gdb) bt
> #0 0x00007fa9248af742 in ReorderBufferGetTupleBuf ()
> #1 0x00007fa9248acde2 in LogicalDecodingProcessRecord ()
> #2 0x00007fa9248b53b4 in ?? ()
> #3 0x00007fa9248b6ed3 in ?? ()
> #4 0x00007fa9248b7d8a in exec_replication_command ()
> #5 0x00007fa9248f39fe in PostgresMain ()
> #6 0x00007fa9246bb92e in ?? ()
> #7 0x00007fa92489e58b in PostmasterMain ()
> #8 0x00007fa9246bcac2 in main ()
Any chance that one of modfied tables in question uses REPLICA IDENTITY
FULL? There's an open bug about too large rows produced by that, which
we don't currently handle correctly. I'm working on fixing that bug.
> What can i do to get more info about the reason of this segfault?
You could post a reproducible example... Other than that it's usually
helpful to build postgres with debugging symbols enabled, that'd already
give more context.
Regards,
Andres Freund