Horton
Menu

Re: [17] CREATE SUBSCRIPTION ... SERVER

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Date: 2023-08-31T05:29:03Z
Lists: pgsql-hackers 
On Wed, Aug 30, 2023 at 9:00 PM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Wed, 2023-08-30 at 19:11 +0530, Ashutosh Bapat wrote:
> > Are you suggesting that SERVERs created with FDW can not be used as
> > publishers?
>
> Correct. Without that, how would the subscription know that the FDW
> contains valid postgres connection information? I suppose it could
> create a connection string out of the options itself and do another
> round of validation, is that what you had in mind?

The server's FDW has to be postgres_fdw. So we have to handle the
awkward dependency between core and postgres_fdw (an extension). The
connection string should be created from options itself. A special
user mapping for replication may be used. That's how I see it at a
high level.

-- 
Best Wishes,
Ashutosh Bapat

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.