Re: error “server process was terminated by signal 11: Segmentation fault” running pg_create_logical_replication_slot using pgoutput plugin - Mailing list pgsql-general

On Wed, 9 Jul 2025 at 12:19, Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>
> On Wed, 9 Jul 2025 at 11:43, abrahim abrahao <a_abrahao@yahoo.com.br> wrote:
> >
> > I got error “server process was terminated by signal 11: Segmentation fault” using
pg_create_logical_replication_slotwith 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.4482025-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.4482025-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.44d2025-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.007s, 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@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.4482025-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@lists.postgresql.org

Thanks and Regards,
Shlok Kyal