Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Sun, 15 Sep 2019 at 12:20, Tomas Vondra wrote: > > On Sun, Sep 15, 2019 at 11:27:19AM +0100, Dean Rasheed wrote: > >On Sun, 15 Sep 2019 at 11:11, Tomas Vondra > >wrote: > >> > >> On Sun, Sep 15, 2019 at 10:16:30AM +0100, Dean Rasheed wrote: > >> > > >> >Ah sorry, I missed this thread before. As author of that commit, it's > >> >really on me to fix it, and the cause seems pretty clear-cut, so I'll > >> >aim to get that done today. > >> > >> FWIW here is a draft patch that I was going to propose - it simply moves > >> the table+view into a "tststats" schema. I suppose that's rougly what we > >> discussed earlier in this thread. > >> > > > >Yes, that matches what I just drafted. > >Do you want to push it, or shall I? > > Please go ahead and push. I'm temporarily without commit access. > OK, pushed. Regards, Dean
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Sun, Sep 15, 2019 at 11:27:19AM +0100, Dean Rasheed wrote: On Sun, 15 Sep 2019 at 11:11, Tomas Vondra wrote: On Sun, Sep 15, 2019 at 10:16:30AM +0100, Dean Rasheed wrote: > >Ah sorry, I missed this thread before. As author of that commit, it's >really on me to fix it, and the cause seems pretty clear-cut, so I'll >aim to get that done today. FWIW here is a draft patch that I was going to propose - it simply moves the table+view into a "tststats" schema. I suppose that's rougly what we discussed earlier in this thread. Yes, that matches what I just drafted. Do you want to push it, or shall I? Please go ahead and push. I'm temporarily without commit access. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Sun, 15 Sep 2019 at 11:11, Tomas Vondra wrote: > > On Sun, Sep 15, 2019 at 10:16:30AM +0100, Dean Rasheed wrote: > > > >Ah sorry, I missed this thread before. As author of that commit, it's > >really on me to fix it, and the cause seems pretty clear-cut, so I'll > >aim to get that done today. > > FWIW here is a draft patch that I was going to propose - it simply moves > the table+view into a "tststats" schema. I suppose that's rougly what we > discussed earlier in this thread. > Yes, that matches what I just drafted. Do you want to push it, or shall I? Regards, Dean
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Sun, Sep 15, 2019 at 10:16:30AM +0100, Dean Rasheed wrote: On Sat, 14 Sep 2019 at 05:25, Tom Lane wrote: Tomas Vondra writes: > On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote: >> On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote: >>> Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously >>> changed one of the other tests that run concurrently with "rules"? >> Looks like stats_ext.sql could be the problem. It creates and drops >> priv_test_view, not in a schema. Adding Dean, author of commit >> d7f8d26d. > Yeah, that seems like it might be the cause. I'll take a look at fixing > this, probably by creating the view in a different schema. Ping? We're still getting intermittent failures of this ilk, eg https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet=2019-09-14%2003%3A37%3A03 With v12 release approaching, I'd like to not have failures like this in a released branch. Ah sorry, I missed this thread before. As author of that commit, it's really on me to fix it, and the cause seems pretty clear-cut, so I'll aim to get that done today. FWIW here is a draft patch that I was going to propose - it simply moves the table+view into a "tststats" schema. I suppose that's rougly what we discussed earlier in this thread. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services diff --git a/src/test/regress/expected/stats_ext.out b/src/test/regress/expected/stats_ext.out index e56c75cd33..b2fb260172 100644 --- a/src/test/regress/expected/stats_ext.out +++ b/src/test/regress/expected/stats_ext.out @@ -752,19 +752,21 @@ SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND -- the underlying table. -- -- Currently this is only relevant for MCV stats. -CREATE TABLE priv_test_tbl ( +CREATE schema tststats; +CREATE TABLE tststats.priv_test_tbl ( a int, b int ); -INSERT INTO priv_test_tbl +INSERT INTO tststats.priv_test_tbl SELECT mod(i,5), mod(i,10) FROM generate_series(1,100) s(i); -CREATE STATISTICS priv_test_stats (mcv) ON a, b - FROM priv_test_tbl; -ANALYZE priv_test_tbl; +CREATE STATISTICS tststats.priv_test_stats (mcv) ON a, b + FROM tststats.priv_test_tbl; +ANALYZE tststats.priv_test_tbl; -- User with no access CREATE USER regress_stats_user1; +GRANT USAGE ON SCHEMA tststats TO regress_stats_user1; SET SESSION AUTHORIZATION regress_stats_user1; -SELECT * FROM priv_test_tbl; -- Permission denied +SELECT * FROM tststats.priv_test_tbl; -- Permission denied ERROR: permission denied for table priv_test_tbl -- Attempt to gain access using a leaky operator CREATE FUNCTION op_leak(int, int) RETURNS bool @@ -772,39 +774,41 @@ CREATE FUNCTION op_leak(int, int) RETURNS bool LANGUAGE plpgsql; CREATE OPERATOR <<< (procedure = op_leak, leftarg = int, rightarg = int, restrict = scalarltsel); -SELECT * FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied +SELECT * FROM tststats.priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied ERROR: permission denied for table priv_test_tbl -DELETE FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied +DELETE FROM tststats.priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied ERROR: permission denied for table priv_test_tbl -- Grant access via a security barrier view, but hide all data RESET SESSION AUTHORIZATION; -CREATE VIEW priv_test_view WITH (security_barrier=true) -AS SELECT * FROM priv_test_tbl WHERE false; -GRANT SELECT, DELETE ON priv_test_view TO regress_stats_user1; +CREATE VIEW tststats.priv_test_view WITH (security_barrier=true) +AS SELECT * FROM tststats.priv_test_tbl WHERE false; +GRANT SELECT, DELETE ON tststats.priv_test_view TO regress_stats_user1; -- Should now have access via the view, but see nothing and leak nothing SET SESSION AUTHORIZATION regress_stats_user1; -SELECT * FROM priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak +SELECT * FROM tststats.priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak a | b ---+--- (0 rows) -DELETE FROM priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak +DELETE FROM tststats.priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak -- Grant table access, but hide all data with RLS RESET SESSION AUTHORIZATION; -ALTER TABLE priv_test_tbl ENABLE ROW LEVEL SECURITY; -GRANT SELECT, DELETE ON priv_test_tbl TO regress_stats_user1; +ALTER TABLE tststats.priv_test_tbl ENABLE ROW LEVEL SECURITY; +GRANT SELECT, DELETE ON tststats.priv_test_tbl TO regress_stats_user1; -- Should now have direct table access, but see nothing and leak nothing SET SESSION AUTHORIZATION regress_stats_user1; -SELECT * FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Should not leak +SELECT * FROM tststats.priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Should not leak a | b ---+--- (0 rows) -DELETE FROM priv_test_tbl WHERE a <<< 0 AND
Re: BF failure: could not open relation with OID XXXX while querying pg_views
Tomas Vondra writes: > On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote: >> On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote: >>> Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously >>> changed one of the other tests that run concurrently with "rules"? >> Looks like stats_ext.sql could be the problem. It creates and drops >> priv_test_view, not in a schema. Adding Dean, author of commit >> d7f8d26d. > Yeah, that seems like it might be the cause. I'll take a look at fixing > this, probably by creating the view in a different schema. Ping? We're still getting intermittent failures of this ilk, eg https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet=2019-09-14%2003%3A37%3A03 With v12 release approaching, I'd like to not have failures like this in a released branch. regards, tom lane
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote: On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote: Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously changed one of the other tests that run concurrently with "rules"? Looks like stats_ext.sql could be the problem. It creates and drops priv_test_view, not in a schema. Adding Dean, author of commit d7f8d26d. Yeah, that seems like it might be the cause. I'll take a look at fixing this, probably by creating the view in a different schema. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote: > Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously > changed one of the other tests that run concurrently with "rules"? Looks like stats_ext.sql could be the problem. It creates and drops priv_test_view, not in a schema. Adding Dean, author of commit d7f8d26d. -- Thomas Munro https://enterprisedb.com
Re: BF failure: could not open relation with OID XXXX while querying pg_views
Peter Eisentraut writes: > On 2019-08-14 05:52, Tom Lane wrote: >> Thomas Munro writes: >>> They all raised "ERROR: could not open relation with OID " >>> while running: >>> SELECT viewname, definition FROM pg_views >>> WHERE schemaname IN ('pg_catalog', 'public') >>> ORDER BY viewname; >> I think the problem is probably that Peter ignored this bit of advice >> in parallel_schedule: >> # rules cannot run concurrently with any test that creates >> # a view or rule in the public schema >> when he inserted "collate.linux.utf8" concurrently with "rules". > This test file is set up to create everything in the "collate_tests" > schema. Is that not working correctly? Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously changed one of the other tests that run concurrently with "rules"? regards, tom lane
Re: BF failure: could not open relation with OID XXXX while querying pg_views
On 2019-08-14 05:52, Tom Lane wrote: > Thomas Munro writes: >> Here are three strange recent failures in the "rules" test: >> ... >> They all raised "ERROR: could not open relation with OID " >> while running: >> SELECT viewname, definition FROM pg_views >> WHERE schemaname IN ('pg_catalog', 'public') >> ORDER BY viewname; > > I think the problem is probably that Peter ignored this bit of advice > in parallel_schedule: > > # rules cannot run concurrently with any test that creates > # a view or rule in the public schema > > when he inserted "collate.linux.utf8" concurrently with "rules". This test file is set up to create everything in the "collate_tests" schema. Is that not working correctly? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: BF failure: could not open relation with OID XXXX while querying pg_views
Thomas Munro writes: > Here are three strange recent failures in the "rules" test: > ... > They all raised "ERROR: could not open relation with OID " > while running: > SELECT viewname, definition FROM pg_views > WHERE schemaname IN ('pg_catalog', 'public') > ORDER BY viewname; I think the problem is probably that Peter ignored this bit of advice in parallel_schedule: # rules cannot run concurrently with any test that creates # a view or rule in the public schema when he inserted "collate.linux.utf8" concurrently with "rules". (I suspect BTW that the point is not so much that you better not *create* such an object, as that you better not *drop* it concurrently with that query.) regards, tom lane
BF failure: could not open relation with OID XXXX while querying pg_views
Hi, Here are three strange recent failures in the "rules" test: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=blenny=2019-08-13%2022:19:27 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alewife=2019-07-27%2009:39:05 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory=2019-07-18%2003:00:27 They all raised "ERROR: could not open relation with OID " while running: SELECT viewname, definition FROM pg_views WHERE schemaname IN ('pg_catalog', 'public') ORDER BY viewname; -- Thomas Munro https://enterprisedb.com