Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1JrojFWnyzWES6ME-q=j2Kg0vV+gv-Rp3-P1v06QyGEJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Список | 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 по дате отправления: