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

From: abrahim abrahao <[email-masked]>
Date: Tue, 8 Jul 2025 17:54:07 +0000 (UTC)

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 = 20listen_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@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

---

From: Shlok Kyal <[email-masked]>
Date: Wed, 9 Jul 2025 12:19:33 +0530

On Wed, 9 Jul 2025 at 11:43, abrahim abrahao <[email-masked]> wrote:
> 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 = '*'
>
>
>

Hi Abrahim,

Can you also share the stack trace for the crash?
Also can you share the exact steps used to reproduce the issue?

Thanks and Regards,
Shlok Kyal

---

From: Shlok Kyal <[email-masked]>
Date: Wed, 9 Jul 2025 13:57:42 +0530

> > < 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]: [email-masked]

Thanks and Regards,
Shlok Kyal

---

From: "Hayato Kuroda (Fujitsu)" <[email-masked]>
Date: Thu, 10 Jul 2025 02:18:59 +0000

Dear Shlok, Abrahim,

> > > < 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
> 

I found the output in Citus source code [1]. So, I'm afraid that you may load the
shared library provided by Citus when you created the replication slot.

If so, Citus community may be the better place to discuss the bug.
We can help if you can reproduce the bug by the PostgreSQL core codes.

[1]: https://github.com/citusdata/citus/blob/5deaf9a61673e10c183b6d4f13593f168e1c2c10/src/backend/distributed/cdc/cdc_decoder.c#L85

Best regards,
Hayato Kuroda
FUJITSU LIMITED

---

From: abrahim abrahao <[email-masked]>
Date: Thu, 10 Jul 2025 17:33:21 +0000 (UTC)

Thanks  Hayato and Shlok, The Citus extension package is installed, but it is not preload on shared_preload_libraries and citus extesion is not created.I will create a new container without Citus extension package and adding stack trace ( I think this is the one you're talking about) as soon as possible and I will update here as soon I complete the test.
See information below.
show shared_preload_libraries;   shared_preload_libraries------------------------------- pg_stat_statements, pg_repack(1 row)
\dx                                            List of installed extensions        Name        | Version |   Schema   |                              Description--------------------+---------+------------+------------------------------------------------------------------------ btree_gist         | 1.7     | public     | support for indexing common datatypes in GiST ltree              | 1.2     | public     | data type for hierarchical tree-like structures pg_stat_statements | 1.10    | public     | track planning and execution statistics of all SQL statements executed pg_trgm            | 1.5     | public     | text similarity measurement and index searching based on trigrams pgcrypto           | 1.3     | public     | cryptographic functions plpgsql            | 1.0     | pg_catalog | PL/pgSQL procedural language postgis            | 3.5.1   | public     | PostGIS geometry and geography spatial types and functions uuid-ossp          | 1.1     | public     | generate universally unique identifiers (UUIDs)(8 rows)

Steps done until pg_create_logical_replication_slot command (just the steps, does not include the full command)
set wal_level, max_replication_slots, max_wal_senders and listen_addresses         name          | setting-----------------------+--------- listen_addresses      | * max_replication_slots | 10 max_wal_senders       | 20 wal_level             | logical
Changed pg_hba filerestart databasepg_ctl restart -D $POSTGRESQL_DATA
create a user "CREATE USER user_rep WITH REPLICATION ENCRYPTED PASSWORD"ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myg GRANT SELECT ON TABLES TO user_rep;CREATE PUBLICATION myg_pub FOR TABLES IN SCHEMA myg;ALTER PUBLICATION myg_pub ADD TABLE myg
SELECT snapshot_name FROM pg_create_logical_replication_slot

    On Wednesday, July 9, 2025 at 10:19:07 p.m. EDT, Hayato Kuroda (Fujitsu) <[email-masked]> wrote:  
 
 Dear Shlok, Abrahim,

Best regards,
Hayato Kuroda
FUJITSU LIMITED