Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
Date: 2023-10-02 08:53:22
Message-ID: 566c1686-c80b-4d4a-b496-b00ac428a095@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2023-10-02 09:15:09 Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound
Previous Message Peter Eisentraut 2023-10-02 08:47:48 Re: Pre-proposal: unicode normalized text