From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION |
Date: | 2020-05-19 21:07:28 |
Message-ID: | DF141796-500F-4A3B-8217-A0368AC35FAC@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 19 May 2020, at 17:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 13 Feb 2020, at 23:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Given the current behavior of SET ROLE and SET SESSION AUTHORIZATION,
>>> I don't actually see any way that we could get these features to
>>> play together.
>
>> Is this being worked on for the 13 cycle such that it should be an open item?
>
> I didn't have it on my list, but yeah maybe we should add it to the
> "pre-existing issues" list.
>
>>> The quick-and-dirty answer is to disallow these switches from being
>>> used together in pg_restore, and I'm inclined to think maybe we should
>>> do that in the back branches.
>
>> ..or should we do this for v13 and back-branches and leave fixing it for 14?
>> Considering the potential invasiveness of the fix I think the latter sounds
>> rather appealing at this point in the cycle. Something like the attached
>> should be enough IIUC.
>
> pg_dump and pg_dumpall also have that switch no?
They do, but there the switches actually work as intended and the combination
should be allowed AFAICT. Since SET ROLE is sent to the source server and not
the output we can use for starting the dump without being a superuser.
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-05-19 23:31:29 | Re: pg_stat_wal_receiver and flushedUpto/writtenUpto |
Previous Message | Thomas Munro | 2020-05-19 20:30:33 | Re: Two fsync related performance issues? |