Обсуждение: 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
Re: BF failure: could not open relation with OID XXXX while queryingpg_views
От
Peter Eisentraut
Дата:
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 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
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
Вложения
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