Обсуждение: How to use set/reset role in contrib_regression test?
Hello! I hope this is the right list for extension dev questions?
SELECT CURRENT_ROLE;
current_user
--------------
jfinzel
(1 row)
SET ROLE test_pgl_ddl_deploy;
SELECT CURRENT_ROLE;
current_user
---------------------
test_pgl_ddl_deploy
(1 row)
RESET ROLE;
SELECT CURRENT_ROLE;
current_user
--------------
jfinzel
(1 row)
SET ROLE test_pgl_ddl_deploy;
CREATE SCHEMA special;
CREATE TABLE special.foo (id serial primary key, foo text, bar text);
CREATE TABLE special.bar (id serial primary key, super text, man text);
SELECT CURRENT_ROLE;
current_user
---------------------
test_pgl_ddl_deploy
(1 row)
RESET ROLE;
SELECT CURRENT_ROLE;
current_user
---------------------
test_pgl_ddl_deploy
(1 row)
SET SESSION AUTHORIZATION DEFAULT;
RESET ROLE;
SELECT CURRENT_ROLE;
current_user
---------------------
test_pgl_ddl_deploy
(1 row)
What am I missing here? Any comments much appreciated.
Thanks,
Jeremy Finzel
Hello! I hope this is the right list for extension dev questions?SELECT CURRENT_ROLE;current_user--------------jfinzel(1 row)SET ROLE test_pgl_ddl_deploy;CREATE SCHEMA special;CREATE TABLE special.foo (id serial primary key, foo text, bar text);CREATE TABLE special.bar (id serial primary key, super text, man text);RESET ROLE;SELECT CURRENT_ROLE;current_user---------------------test_pgl_ddl_deploy(1 row)What am I missing here? Any comments much appreciated.
Probably -bugs (or -general if you are unsure about the buggy-ness) would have been a more appropriate list since this is all direct SQL that looks to be broken. No use moving it now, though.
Reporting the version(s) you are running would be helpful.
David J.
On Fri, Dec 8, 2017 at 8:12 AM, David G. Johnston <david.g.johnston@gmail.com> wrote: > Probably -bugs (or -general if you are unsure about the buggy-ness) would > have been a more appropriate list since this is all direct SQL that looks to > be broken. No use moving it now, though. On HEAD, REL_10_STABLE or REL9_6_STABLE, say with two users: =# create role popo1 superuser login; CREATE ROLE Time: 9.400 ms =# create role popo2 login; CREATE ROLE And then by creating objects: =# select current_role; current_user -------------- popo1 (1 row) =# set role popo2; SET => select current_role; current_user -------------- popo2 (1 row) => create table aa (a int); CREATE TABLE => select current_role; current_user -------------- popo2 (1 row) => reset role; RESET =# select current_role; current_user -------------- popo1 (1 row) Per the information you are giving, I would have seen "popo2" as user for the last query even after issuing a RESET ROLE. However I do not see any problems. > Reporting the version(s) you are running would be helpful. Indeed. -- Michael
Michael Paquier <michael.paquier@gmail.com> writes:
> Per the information you are giving, I would have seen "popo2" as user
> for the last query even after issuing a RESET ROLE. However I do not
> see any problems.
Yeah, I also failed to reproduce it (on yesterday's HEAD, though I'd be
surprised if older versions were busted like this either). I'm wondering
if Jeremy has some extension installed that is messing with the behavior.
regards, tom lane
Here is my version:
PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit
Indeed it is possible my extension is messing up the behavior because event triggers are firing on the CREATE events. But there is no SET ROLE happening in the event triggers.
Perhaps one of the more interesting things happening is there is the pglogical c function pglogical.replicate_ddl_command that is being called. I do see some interesting things happening with roles here, specifically this: https://github.com/2ndQuadrant/pglogical/blob/REL1_2_STABLE/pglogical_apply.c#L1699-L1704
Added Craig Ringer to the discussion in case he has any ideas on if that could be a factor.
On Fri, Dec 8, 2017 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
> Per the information you are giving, I would have seen "popo2" as user
> for the last query even after issuing a RESET ROLE. However I do not
> see any problems.
Yeah, I also failed to reproduce it (on yesterday's HEAD, though I'd be
surprised if older versions were busted like this either). I'm wondering
if Jeremy has some extension installed that is messing with the behavior.
regards, tom lane