Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id Zd7UtoSj0FJVk3aF@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Synchronizing slots from primary to standby
List pgsql-hackers
Hi,

On Wed, Feb 28, 2024 at 08:49:19AM +0530, Amit Kapila wrote:
> On Mon, Feb 26, 2024 at 9:13 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Fri, Feb 23, 2024 at 7:41 PM Bertrand Drouvot
> > <bertranddrouvot.pg@gmail.com> wrote:
> > >
> > > Hi,
> > > > I think to set secure search path for remote connection, the standard approach
> > > > could be to extend the code in libpqrcv_connect[1], so that we don't need to schema
> > > > qualify all the operators in the queries.
> > > >
> > > > And for local connection, I agree it's also needed to add a
> > > > SetConfigOption("search_path", "" call in the slotsync worker.
> > > >
> > > > [1]
> > > > libpqrcv_connect
> > > > ...
> > > >       if (logical)
> > > > ...
> > > >               res = libpqrcv_PQexec(conn->streamConn,
> > > >                                                         ALWAYS_SECURE_SEARCH_PATH_SQL);
> > > >
> > >
> > > Agree, something like in the attached? (it's .txt to not disturb the CF bot).
> >
> > Thanks for the patch, changes look good. I have corporated it in the
> > patch which addresses the rest of your comments in [1]. I have
> > attached the patch as .txt
> >
> 
> Few comments:
> ===============
> 1.
> - if (logical)
> + if (logical || !replication)
>   {
> 
> Can we add a comment about connection types that require
> ALWAYS_SECURE_SEARCH_PATH_SQL?

Yeah, will do.

> 
> 2.
> Can we add a test case to demonstrate that the '=' operator can be
> hijacked to do different things when the slotsync worker didn't use
> ALWAYS_SECURE_SEARCH_PATH_SQL?

I don't think that's good to create a test to show how to hijack an operator
within a background worker.

I had a quick look and did not find existing tests in this area around
ALWAYS_SECURE_SEARCH_PATH_SQL / search_patch and background worker.

Such a test would:

- "just" ensure that search_path works as expected
- show how to hijack an operator within a background worker

Based on the above I don't think that such a test is worth it.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Injection points: some tools to wait and wake
Next
From: Bharath Rupireddy
Date:
Subject: Re: Add new error_action COPY ON_ERROR "log"