MIME-Version: 1.0
References: <149ff9264db27cdf724b65709fbbaee4bf316835.camel@j-davis.com>
 <CAExHW5vv-78ixJs3arsuZ+12A4AyqehJnDPhejp0m4FAKG6JZA@mail.gmail.com>
 <830a2bc6cbbb2e6e01c6c0d9f31f320822e10603.camel@j-davis.com>
 <CAExHW5sAo4Gv3AwuxQNGSQ2Z45B8_MZEb-SG-B8D-hLMdrquAg@mail.gmail.com>
 <e531ec798298a21d671babd45849092850b8675e.camel@j-davis.com>
 <ac4042d6-204c-9661-9949-79ab8a1f8604@joeconway.com>
 <CAExHW5unvpDv6yMSmqurHP7Du1PqoJFWVxeK-4YNm5EnoNJiSQ@mail.gmail.com>
 <433d0845248e86c0317d9d396926182cfe157340.camel@j-davis.com>
 <CAExHW5sQVJeCgCGMkum_k4Z4VPaK5GkdAjHW-d+F3MngBZ9qBA@mail.gmail.com>
 <05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com>
 <93392ffa941ab0d436e19e0ab5d04d0e42c02d3f.camel@j-davis.com>
 <26be917cb07b6aa3ef5dd15f6b59d1b375ece6e8.camel@j-davis.com>
 <CALj2ACXDua2Az15Kj3OZFaRm49G8-faemiEEv8t9GNCcsxv8Hw@mail.gmail.com>
 <55201bd916e748acfc754c8f95880dae8e4e5ed0.camel@j-davis.com>
 <CAExHW5v5poohyfNRVQp3yjVE56ej0dWvVMbysSSVtg21aHT3uQ@mail.gmail.com>
 <e71e029309171eb8b6ca393306f9bc5acfbfdf8f.camel@j-davis.com>
 <CAExHW5vF+cp9efQj=-W+Rhbr9f9ZZqt3XFnP0NB5jKsm=C=5tw@mail.gmail.com>
 <2a89b14a2b1622bffb8b137ca1f9ab7866f2d2b9.camel@j-davis.com>
 <61831790a0a937038f78ce09f8dd4cef7de7456a.camel@j-davis.com>
 <CAExHW5uCzS-VeSYQHTHxFSdQik-f_O892xmzrzm2fuO+ro+otA@mail.gmail.com>
 <0910b47040406c1d24ec0150dafb5bae6b910ed7.camel@j-davis.com>
 <CAExHW5vDPBB_PShBmSj=v=Jf1K=vSmWdPZTzCJsLpqDgqek+sA@mail.gmail.com>
 <7338f22c4534322a08ab6ce9f879e2e308eb5e5d.camel@j-davis.com>
 <CAExHW5uirmv8tj7LJ3zDo2tfaP_fffAeRbKT--3vBe7pa0in0g@mail.gmail.com>
 <d233117a82774de6e606cb383d1e0efea72c8879.camel@j-davis.com>
 <CAExHW5v5yn7HSD86OJ+Fj-FUcZK4mT40i7DBZoU2hQwfpeYLvw@mail.gmail.com>
 <e0914faf80f4f7f099f6f33597dd3b0f75779cec.camel@j-davis.com>
 <34fd5885b8245d1014f4426ea22af61229d42e3e.camel@j-davis.com>
 <e37776aa4d5679e2efc7d81e7dae4a8998658e37.camel@j-davis.com>
 <e0c6fd0fa6036df36779c8bd8ae763c6f4064135.camel@j-davis.com>
 <CANhcyEUoJeXw2W8TtUZRK48YLuV7R_cKsu=KfvgCAh0YqCC4gw@mail.gmail.com>
 <7a5df376fffb273430aec9e89f88c31d52dcf295.camel@j-davis.com>
 <5dfe845221db2e7d38fc7c2a18a4ba5ea29cdfc0.camel@j-davis.com>
 <CAD21AoA3dOqh4DeRtLJjzBxYaMfmzxw+s9tMo_wgnV7RdfUvtA@mail.gmail.com>
 <60ff024706fe1beab62a89ac07eb6a721856de2e.camel@j-davis.com>
 <b881ea575dab426422e483ab7edfcd98b532cbef.camel@j-davis.com>
 <CAA4eK1K79RCQ-WrN3gvdC=HzRcpeOhho+kWWKWatKzm4v_aypg@mail.gmail.com>
 <80303af653a3da2a94e32ff91d6538675e921bf0.camel@j-davis.com>
 <CAExHW5vV5znEvecX=ra2-v7UBj9-M6qvdDzuB78M-TxbYD1PEA@mail.gmail.com>
 <7eb0c03b4312b32cb76d340023b39a751745a1f9.camel@j-davis.com>
 <CAA4eK1K=WjZ1maBCmj=5ZdO66AwPORK5ZBxVKedS0xdCcb621A@mail.gmail.com>
 <25e841738fba648755cb3882327f4744f4c8cfe9.camel@j-davis.com>
In-Reply-To: <25e841738fba648755cb3882327f4744f4c8cfe9.camel@j-davis.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 17 Mar 2026 11:29:40 +0530
Message-ID: 
 <CAA4eK1LGJfoCHPNCr5_m2sCMhVO6jqvotAxfcCOyNUZUPPFp0A@mail.gmail.com>
Subject: Re: [19] CREATE SUBSCRIPTION ... SERVER
To: Jeff Davis <pgsql@j-davis.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
	Shlok Kyal <shlok.kyal.oss@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Joe Conway <mail@joeconway.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1LGJfoCHPNCr5_m2sCMhVO6jqvotAxfcCOyNUZUPPFp0A%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 16, 2026 at 9:56=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrot=
e:
>
> 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.

--=20
With Regards,
Amit Kapila.