From: Tom Lane <tgl@sss.pgh.pa.us>
To: sergey.belyashov@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18815: Logical replication worker Segmentation fault
In-reply-to: <18815-2a0407cc7f40b327@postgresql.org>
References: <18815-2a0407cc7f40b327@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 17 Feb 2025 10:52:32 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <832224.1739810351.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Feb 2025 11:39:11 -0500
Message-ID: <832225.1739810351@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/832225.1739810351%40sss.pgh.pa.us>
Precedence: bulk

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=3Dfalse
> (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 no=
t
> come immediately after subscription creation, but it cause when data is =
come
> from the publisher. Then subscriber is restarts, recover, run subscripti=
on
> 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