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&dt=2019-08-13%2022:19:27
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alewife&dt=2019-07-27%2009:39:05
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2019-07-18%2003:00:27
They all raised "ERROR: could not open relation with OID <varies>"
while running:
SELECT viewname, definition FROM pg_views
WHERE schemaname IN ('pg_catalog', 'public')
ORDER BY viewname;
--
Thomas Munro
https://enterprisedb.com
Thomas Munro <thomas.munro@gmail.com> writes:
Here are three strange recent failures in the "rules" test:
...
They all raised "ERROR: could not open relation with OID <varies>"
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
On 2019-08-14 05:52, Tom Lane wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
Here are three strange recent failures in the "rules" test:
...
They all raised "ERROR: could not open relation with OID <varies>"
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 schemawhen 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
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2019-08-14 05:52, Tom Lane wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
They all raised "ERROR: could not open relation with OID <varies>"
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
On Wed, Aug 14, 2019 at 5:06 PM Tom Lane <tgl@sss.pgh.pa.us> 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
On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote:
On Wed, Aug 14, 2019 at 5:06 PM Tom Lane <tgl@sss.pgh.pa.us> 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
Tomas Vondra <tomas.vondra@2ndquadrant.com> 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 <tgl@sss.pgh.pa.us> 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&dt=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
On Sat, 14 Sep 2019 at 05:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tomas Vondra <tomas.vondra@2ndquadrant.com> 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 <tgl@sss.pgh.pa.us> 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&dt=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.
Regards,
Dean
On Sun, Sep 15, 2019 at 10:16:30AM +0100, Dean Rasheed wrote:
On Sat, 14 Sep 2019 at 05:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tomas Vondra <tomas.vondra@2ndquadrant.com> 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 <tgl@sss.pgh.pa.us> 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&dt=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
Attachments:
stats_ext_view.patchtext/plain; charset=us-asciiDownload+45-38
On Sun, 15 Sep 2019 at 11:11, Tomas Vondra <tomas.vondra@2ndquadrant.com> 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
On Sun, Sep 15, 2019 at 11:27:19AM +0100, Dean Rasheed wrote:
On Sun, 15 Sep 2019 at 11:11, Tomas Vondra <tomas.vondra@2ndquadrant.com> 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
On Sun, 15 Sep 2019 at 12:20, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On Sun, Sep 15, 2019 at 11:27:19AM +0100, Dean Rasheed wrote:
On Sun, 15 Sep 2019 at 11:11, Tomas Vondra <tomas.vondra@2ndquadrant.com> 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