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

From Jeff Davis
Subject Re: [17] CREATE SUBSCRIPTION ... SERVER
Date
Msg-id 05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com
Whole thread Raw
In response to Re: [17] CREATE SUBSCRIPTION ... SERVER  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: [17] CREATE SUBSCRIPTION ... SERVER
Re: [17] CREATE SUBSCRIPTION ... SERVER
List pgsql-hackers
On Mon, 2023-09-04 at 18:01 +0530, Ashutosh Bapat wrote:
> 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.

"Constantly" was an exaggeration, but the point is that it's a separate
validation step after the ALTER SERVER or ALTER USER MAPPING has
already happened, so the subscription would start failing.

Perhaps this is OK, but it's not the ideal user experience. Ideally,
the user would get some indication from the ALTER SERVER or ALTER USER
MAPPING that it's about to break a subscription that depends on it.

> I didn't understand your worry about circumventing password_required
> protection.

If the subscription doesn't do its own validation, and if the FDW
doesn't ensure that the password is set, then it could end up creating
a creating a connection string without supplying the password.

> We don't need to if we allow any FDW (even if non-postgreSQL) to be
> specified there.

OK, so we could have a built-in FDW called pg_connection that would do
the right kinds of validation; and then also allow other FDWs but the
subscription would have to do its own validation.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improve heapgetpage() performance, overhead from serializable
Next
From: Hannu Krosing
Date:
Subject: Re: Initdb-time block size specification