Re: error “server process was terminated by signal 11: Segmentation fault” running pg_create_logical_replication_slot using pgoutput plugin

On Wed, 9 Jul 2025 at 12:19, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
>
> On Wed, 9 Jul 2025 at 11:43, abrahim abrahao <a_abrahao(at)yahoo(dot)com(dot)br> wrote:
> >
> > I got error “server process was terminated by signal 11: Segmentation fault” using pg_create_logical_replication_slot with pgoutput plugin parameter and using test_decoding worked fine, any idea that is wrong?
> >
> > Note: I am using docker container and I also updated shm-size from 1024mb to 2g and I am using shared_buffers=1.5GB.
> > This is a test server and there is nothing else running. IT is the first time I am working with logical replication.
> >
> > See details below
> >
> > postgresql.conf file:
> > wal_level = logical
> > max_replication_slots = 10
> > max_wal_senders = 20
> > listen_addresses = '*'
> >
> >
> >
> > psql -U postgres -h postgres -c "SELECT pg_create_logical_replication_slot('support7561_repslot', 'pgoutput');"
> > SSL SYSCALL error: EOF detected
> > connection to server was lost
> >
> >
> > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414) SELECT 00000 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08 14:57:08.653 UTC > LOG: Initializing CDC decoder
> > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414) SELECT 00000 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08 14:57:08.653 UTC > STATEMENT: SELECT pg_create_logical_replication_slot('support7561_repslot', 'pgoutput');
> > < 2025-07-08 14:57:08.821 UTC 00000 2025-07-08 14:55:38 UTC 923 686d316a.39b 2025-07-08 14:57:08.821 UTC > LOG: server process (PID 1096) was terminated by signal 11: Segmentation fault
> > < 2025-07-08 14:57:08.821 UTC 00000 2025-07-08 14:55:38 UTC 923 686d316a.39b 2025-07-08 14:57:08.821 UTC > DETAIL: Failed process was running: SELECT pg_create_logical_replication_slot('support7561_repslot', 'pgoutput');
> > < 2025-07-08 14:57:08.821 UTC 00000 2025-07-08 14:55:38 UTC 923 686d316a.39b 2025-07-08 14:57:08.821 UTC > LOG: terminating any other active server processes
> > < 2025-07-08 14:57:08.829 UTC 00000 2025-07-08 14:55:38 UTC 923 686d316a.39b 2025-07-08 14:57:08.829 UTC > LOG: all server processes terminated; reinitializing
> > < 2025-07-08 14:57:09.215 UTC 00000 2025-07-08 14:57:09 UTC 1098 686d31c5.44a 2025-07-08 14:57:09.215 UTC > LOG: database system was interrupted; last known up at 2025-07-08 14:55:39 UTC
> > < 2025-07-08 14:57:10.037 UTC [unknown] postgres postgres 172.18.0.217(33506) 57P03 2025-07-08 14:57:10 UTC 1101 686d31c6.44d 2025-07-08 14:57:10.037 UTC > FATAL: the database system is in recovery mode
> > < 2025-07-08 14:57:10.437 UTC 00000 2025-07-08 14:57:09 UTC 1098 686d31c5.44a 2025-07-08 14:57:10.437 UTC > LOG: database system was not properly shut down; automatic recovery in progress
> > < 2025-07-08 14:57:10.450 UTC 00000 2025-07-08 14:57:09 UTC 1098 686d31c5.44a 2025-07-08 14:57:10.450 UTC > LOG: redo starts at 1FB9/C0000A0
> > < 2025-07-08 14:57:10.456 UTC 00000 2025-07-08 14:57:09 UTC 1098 686d31c5.44a 2025-07-08 14:57:10.456 UTC > LOG: invalid record length at 1FB9/C054DF8: wanted 24, got 0
> > < 2025-07-08 14:57:10.456 UTC 00000 2025-07-08 14:57:09 UTC 1098 686d31c5.44a 2025-07-08 14:57:10.456 UTC > LOG: redo done at 1FB9/C054DC0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
> > < 2025-07-08 14:57:10.475 UTC 00000 2025-07-08 14:57:09 UTC 1099 686d31c5.44b 2025-07-08 14:57:10.475 UTC > LOG: checkpoint starting: end-of-recovery immediate wait
> > < 2025-07-08 14:57:10.501 UTC 00000 2025-07-08 14:57:09 UTC 1099 686d31c5.44b 2025-07-08 14:57:10.501 UTC > LOG: checkpoint complete: wrote 86 buffers (0.0%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.010 s, sync=0.007 s, total=0.028 s; sync files=18, longest=0.003 s, average=0.001 s; distance=339 kB, estimate=339 kB
> > < 2025-07-08 14:57:10.510 UTC 00000 2025-07-08 14:55:38 UTC 923 686d316a.39b 2025-07-08 14:57:10.510 UTC > LOG: database system is ready to accept connections
> >
> >
> > psql -U postgres -h postgres -c "SELECT pg_create_logical_replication_slot('support7561_repslot', 'test_decoding');"
> > pg_create_logical_replication_slot
> > ------------------------------------
> > (support7561_repslot,1FB9/C081668)
> > (1 row)
> >
> > postgres(at)support7560_postgres:/var/lib/postgresql/15/main$ psql -U postgres -h postgres -c "SELECT slot_name, plugin, slot_type, database, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;"
> > slot_name | plugin | slot_type | database | active | restart_lsn | confirmed_flush_lsn
> > ---------------------+---------------+-----------+----------+--------+--------------+---------------------
> > support7561_repslot | test_decoding | logical | postgres | f | 1FB9/C081630 | 1FB9/C081668
> >
> >
> > SHOW shared_buffers;
> > shared_buffers
> > ----------------
> > 1532512kB
> > (1 row)
> >
> > postgres=# \! uname -a
> > Linux support7560_postgres 6.8.0-1030-gcp #32~22.04.1-Ubuntu SMP Tue Apr 29 23:17:09 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
> >
> > psql -U postgres -h postgres -c "select version()"
> > version
> > -------------------------------------------------------------------------------------------------------------------------------------
> > PostgreSQL 15.13 (Ubuntu 15.13-1.pgdg24.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, 64-bit
>
> Hi Abrahim,
>
> Can you also share the stack trace for the crash?
> Also can you share the exact steps used to reproduce the issue?
>

Also, I was going to the logs on found:
> > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414) SELECT 00000 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08 14:57:08.653 UTC > LOG: Initializing CDC decoder

This log is not present in Postgres source code. Why is this log appearing here?
Also I would suggest you to post this issue in pgsql-hackers mailing list [1].

[1]: pgsql-hackers(at)lists(dot)postgresql(dot)org

Thanks and Regards,
Shlok Kyal