Re: [19] CREATE SUBSCRIPTION ... SERVER - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [19] CREATE SUBSCRIPTION ... SERVER
Date
Msg-id CAA4eK1LGJfoCHPNCr5_m2sCMhVO6jqvotAxfcCOyNUZUPPFp0A@mail.gmail.com
Whole thread Raw
In response to Re: [19] CREATE SUBSCRIPTION ... SERVER  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: [19] CREATE SUBSCRIPTION ... SERVER
List pgsql-hackers
On Mon, Mar 16, 2026 at 9:56 PM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Mon, 2026-03-16 at 11:08 +0530, Amit Kapila wrote:
> > Won't it be sufficient if we just reset MySubscriptionCtx here or in
> > callback subscription_change_cb()?
>
> The old and new subscriptions are compared against eachother (to see
> whether to restart the worker or not), so they both have to exist at
> the same time. If we put them in the same context, then we can't reset
> it.
>
> I suppose we could have just two contexts and switch back and forth
> between them, resetting the last one. But that doesn't seem to be worth
> the trouble.
>

Yeah, or the other possibility could be to let the newsub information
get allocated in the current transaction context and reset the
subscription context if we decide not to exit from the worker. Then
copy/get the subscription info in subscription context but not sure if
that is worth it. The minor oddity in the proposed approach is that
the worker will exit in many cases after allocating the new context
but that may be the best we can do here.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Next
From: Alexander Lakhin
Date:
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE