Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
| От | Drouvot, Bertrand |
|---|---|
| Тема | Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag |
| Дата | |
| Msg-id | 566c1686-c80b-4d4a-b496-b00ac428a095@gmail.com обсуждение исходный текст |
| Ответ на | Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
|
| Список | pgsql-hackers |
Hi, On 10/2/23 10:17 AM, Michael Paquier wrote: > On Mon, Oct 02, 2023 at 10:01:04AM +0200, Drouvot, Bertrand wrote: >> I think that would make sense to have more flexibility in the worker_spi >> module. I think that could be done in a dedicated patch though. I >> think it makes more sense to have the current patch "focusing" on >> this new flag (while adding a test about it without too much >> refactoring). What about doing the worker_spi module re-factoring >> as a follow up of this one? > > I would do that first, as that's what I usually do, The reason I was thinking not doing that first is that there is no real use case in the current worker_spi module test. > but I see also > your point that this is not mandatory. If you want, I could give it a > shot tomorrow to see where it leads. Oh yeah that would be great (and maybe you already see a use case in the current test). Thanks! >> Oh right, worth to modify 019_replslot_limit.pl, 002_corrupted.pl and >> 001_pg_controldata.pl in a separate patch for consistency? (they are using >> "(stat $node->logfile)[7]" or "(stat($pg_control))[7]"). > > Indeed, that's strange. Let's remove the dependency to stat here. > The other solution is slightly more elegant IMO, as we don't rely on > the position of the result from stat(). Agree, I will propose a new patch for this. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: