Re: pgsql: Recalculate search_path after ALTER ROLE.

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Jeff Davis <jdavis(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Recalculate search_path after ALTER ROLE.
Date: 2023-08-10 06:08:10
Message-ID: 441542f15012666c621814327415a2cbb0960e10.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Wed, 2023-08-09 at 16:12 -0700, Jeff Davis wrote:
> I'm not sure yet, but this looks like a possible pre-existing bug, or
> some incorrect assumption I made in fa2e874946.

Before my commit the behavior is the same. Here's a minimal repro
(debug_parallel_query set to 'on' or 'regress'):

s1:
CREATE USER u1;
SET SESSION AUTHORIZATION u1;

s2:
ALTER ROLE u1 RENAME TO u2;

s1:
SELECT 1;
ERROR: role "u1" does not exist
CONTEXT: while setting parameter "session_authorization" to "u1"

Given that it works fine without parallel query, I'm inclined to call
this a parallel query bug. The error is coming from RestoreGUCState().

That being said, the buildfarm is red after my commit, so unless
someone sees a quick fix here, perhaps I should remove my isolation
test? I don't want to revert my whole commit, because it seems correct
and fixes a separate bug.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2023-08-10 10:05:03 pgsql: Document RelationGetIndexAttrBitmap better
Previous Message John Naylor 2023-08-10 04:46:49 pgsql: Use native CRC instructions on 64-bit LoongArch