Hi, Peter
Here is the backtrace:
Reading symbols from /usr/lib/postgresql/9.5/bin/postgres...(no debugging
symbols found)...done.
[New LWP 33731]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: docker turf 172.30.32.56(50865) SELECT
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fdd58521f20 in ReorderBufferCommit ()
(gdb) bt
#0 0x00007fdd58521f20 in ReorderBufferCommit ()
#1 0x00007fdd5851d7b0 in LogicalDecodingProcessRecord ()
#2 0x00007fdd5851f1c5 in ?? ()
#3 0x00007fdd58466ac2 in ExecMakeTableFunctionResult ()
#4 0x00007fdd5847be52 in ?? ()
#5 0x00007fdd58468c73 in ExecScan ()
#6 0x00007fdd58461498 in ExecProcNode ()
#7 0x00007fdd5845e34e in standard_ExecutorRun ()
#8 0x00007fdd5856b1ff in ?? ()
#9 0x00007fdd5856c808 in PortalRun ()
#10 0x00007fdd58569501 in PostgresMain ()
#11 0x00007fdd58303c31 in ?? ()
#12 0x00007fdd5850d54e in PostmasterMain ()
#13 0x00007fdd58304db7 in main ()
On Wed, Jun 29, 2016 at 9:19 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Jun 29, 2016 at 12:10 AM, <alexey.kuntsevich@gmail.com> wrote:
> > We enabled logical replication on our postgresql cluster, created a new
> > replication slot with vanilla test_decoding decoder and ran an app that
> > polls 10000 rows from this slot once per second. It ran fine for a day,
> > survived several bulk uploads of ~1mln rows until we did bulk upload of
> > ~8mln rows at once. During the upload our postgresql instance
> disconnected
> > all clients and reported that it is in recovery. Core dump was created
> and
> > when we checked the logs we saw
>
> Can you show a backtrace from the coredump?
>
>
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
>
> --
> Peter Geoghegan
>
--
Best regards,
Alexey Kuntsevich
