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

From Amit Kapila
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id CAA4eK1JrojFWnyzWES6ME-q=j2Kg0vV+gv-Rp3-P1v06QyGEJQ@mail.gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Wed, Feb 28, 2024 at 12:31 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> On Wed, Feb 28, 2024 at 06:48:37AM +0000, Zhijie Hou (Fujitsu) wrote:
> > On Wednesday, February 28, 2024 2:38 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
> > > > 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.
> >
> > I think a similar commit 11da970 has added a test for the search_path, e.g.
>
> Oh right, thanks for sharing!
>
> But do we think it's worth to show how to hijack an operator within a background
> worker "just" to verify that the search_path works as expected?
>
> I don't think it's worth it but will do if others have different opinions.
>

I think it is important to add this test because if we break this
behavior for any reason it will be a security hazard. Now, if adding
it increases the timing of the test too much then we should rethink
but otherwise, I don't see any reason not to add this test.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Next
From: jian he
Date:
Subject: Re: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)