Re: [19] CREATE SUBSCRIPTION ... SERVER

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Amit Kapila <amit.kapila16@gmail.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
Date: 2026-03-16T16:26:41Z
Lists: pgsql-hackers
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.

Regards,
	Jeff Davis




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Document new catalog columns, missed in commit 8185bb5347.

  2. Refactor to remove ForeignServerName().

  3. GetSubscription(): use per-object memory context.

  4. Fix dependency on FDW's connection function.

  5. ALTER SUBSCRIPTION ... SERVER test.

  6. Fix pg_dump for CREATE FOREIGN DATA WRAPPER ... CONNECTION.

  7. Clean up postgres_fdw/t/010_subscription.pl.

  8. CREATE SUBSCRIPTION ... SERVER.

  9. Allow upgrades to preserve the full subscription's state.