Horton

Re: BUG #18815: Logical replication worker Segmentation fault

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: sergey.belyashov@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-02-17T16:39:11Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix uninitialized index information access during apply.

  2. Assert that ExecOpenIndices and ExecCloseIndices are not repeated.

  3. Fix crash in brininsertcleanup during logical replication.

PG Bug reporting form <noreply@postgresql.org> writes:
> After some investigations I found that segfault is caused by one type of
> subscriptions: subscription for huge partitioned tables on publisher and
> subscriber (via root), subscriptions are created with data_copy=false
> (source table updated by inserts and partition detaches, and it is huge,
> data transfer is not compressed so it may take a days). Segfault does not
> come immediately after subscription creation, but it cause when data is come
> from the publisher. Then subscriber is restarts, recover, run subscription
> again, catch segfault and repeat again until subscription is disabled.

This is not enough information for anyone else to reproduce the
problem; it very likely depends on details that you haven't mentioned.
Can you create a reproducer case?  I'm hoping for a script that sets
up the necessary tables and subscriptions and populates the tables
with enough dummy data to cause the failure.

Something that might be less work for you is to get a stack trace
from the crash:

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

However, I make no promises that we can isolate the cause from
just a stack trace.  A reproducer would be much better.

			regards, tom lane