Re: [17] CREATE SUBSCRIPTION ... SERVER
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Joe Conway <mail@joeconway.com>, pgsql-hackers@postgresql.org
Date: 2023-09-04T12:31:57Z
Lists: pgsql-hackers
On Sat, Sep 2, 2023 at 12:24 AM Jeff Davis <pgsql@j-davis.com> wrote: > > On Fri, 2023-09-01 at 12:28 +0530, Ashutosh Bapat wrote: > > Thinking larger, how about we allow any FDW to be used here. > > That's a possibility, but I think that means the subscription would > need to constantly re-check the parameters rather than relying on the > FDW's validator. > > Otherwise it might be the wrong kind of FDW, and the user might be able > to circumvent the password_required protection. It might not even be a > postgres-related FDW at all, which would be a bit strange. > > If it's constantly re-checking the parameters then it raises the > possibility that some "ALTER SERVER" or "ALTER USER MAPPING" succeeds > but then subscriptions to that foreign server start failing, which > would not be ideal. But I could be fine with that. Why do we need to re-check parameters constantly? We will need to restart subscriptions which are using the user mapping of FDW when user mapping or server options change. If that mechanism isn't there, we will need to build it. But that's doable. I didn't understand your worry about circumventing password_required protection. > > > But I think there's some value in bringing > > together these two subsystems which deal with foreign data logically > > (as in logical vs physical view of data). > > I still don't understand how a core dependency on an extension would > work. We don't need to if we allow any FDW (even if non-postgreSQL) to be specified there. For non-postgresql FDW the receiver will need to construct the appropriate command and use appropriate protocol to get the changes and apply locally. The server at the other end may not even have logical replication capability. The extension or "input plugin" (as against output plugin) would decide whether it can deal with the foreign server specific logical replication protocol. We add another callback to FDW which can return whether the given foreign server supports logical replication or not. If the users misconfigured, their subscriptions will throw errors. But with this change we open a built-in way to "replicate in" as we have today to "replicate out". -- 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 →
-
Document new catalog columns, missed in commit 8185bb5347.
- 90630ec42939 19 (unreleased) landed
-
Refactor to remove ForeignServerName().
- 11f8018ee678 19 (unreleased) landed
-
GetSubscription(): use per-object memory context.
- f16f5d608ca6 19 (unreleased) landed
-
Fix dependency on FDW's connection function.
- 4a0b46b6e1e4 19 (unreleased) landed
-
ALTER SUBSCRIPTION ... SERVER test.
- 1c5bf1185af0 19 (unreleased) landed
-
Fix pg_dump for CREATE FOREIGN DATA WRAPPER ... CONNECTION.
- b71bf3b84570 19 (unreleased) landed
-
Clean up postgres_fdw/t/010_subscription.pl.
- f4af7849b3db 19 (unreleased) landed
-
CREATE SUBSCRIPTION ... SERVER.
- 8185bb534763 19 (unreleased) landed
-
Allow upgrades to preserve the full subscription's state.
- 9a17be1e244a 17.0 cited