RE: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Jeff Davis' <pgsql(at)j-davis(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: RE: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Date: 2026-08-05 06:43:43
Message-ID: OS9PR01MB121496E377FC5A754B665BB17F5D32@OS9PR01MB12149.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Jeff,

> Can you explain in more detail the problem case? Is it unique to
> server-based subscriptions?

No, I initially thought that it could happen for both cases. But it seems no need to
consider - the invalidation messages can be accepted only at commit or while no
transactions are received. My worry that GetSubscription() and
GetSubscriptionConninfo() may refer the different tuple won't happen.

> Looking at the code it seems that invalidations can be missed if they
> come between the time the catalogs are read and the time that
> MySubscriptionValid is set. But I think that's a pre-existing issue --
> perhaps we should start a new thread about that?

I analyzed and I feel it's not problematic. Yes, if the ALTER SUBSCRIPTION DISABLE
is executed while in the maybe_reread_subscription(), it can be ignored once.
At the end of transaction or end of the loop, the invalidation message for the
subscription can be accepted and MySubscriptionValid can be false, the worker will
exit. This meant the worker can exit after handling the current transaction.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-08-05 06:47:38 Re: Add more tab=completion rules for DROP PROPERTY GRAPH
Previous Message Chao Li 2026-08-05 06:28:24 Re: Reduce memory overheads for storing a Memoize tuple