Re: Catalog domain not-null constraints - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Catalog domain not-null constraints
Date
Msg-id c153870c-0b68-4c95-8e40-47d5d76ac309@eisentraut.org
Whole thread Raw
In response to Re: Catalog domain not-null constraints  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Catalog domain not-null constraints
List pgsql-hackers
On 18.01.24 07:53, Peter Eisentraut wrote:
> On 17.01.24 13:15, vignesh C wrote:
>> One of the test has failed in CFBot at [1] with:
>> diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
>> /tmp/cirrus-ci-build/src/test/regress/results/domain.out
>> --- /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
>> 2024-01-14 15:40:01.793434601 +0000
>> +++ /tmp/cirrus-ci-build/src/test/regress/results/domain.out
>> 2024-01-14 15:42:23.013332625 +0000
>> @@ -1271,11 +1271,4 @@
>>               FROM information_schema.domain_constraints
>>               WHERE domain_name IN ('con', 'dom', 'pos_int', 'things'))
>>     ORDER BY constraint_name;
>> - constraint_catalog | constraint_schema | constraint_name  |   
>> check_clause
>> ---------------------+-------------------+------------------+-------------------
>> - regression         | public            | con_check        | (VALUE > 0)
>> - regression         | public            | meow             | (VALUE < 
>> 11)
>> - regression         | public            | pos_int_check    | (VALUE > 0)
>> - regression         | public            | pos_int_not_null | VALUE IS 
>> NOT NULL
>> -(4 rows)
>> -
>> +ERROR:  could not open relation with OID 36379
>>
>> [1] - https://cirrus-ci.com/task/4536440638406656
>> [2] - 
>> https://api.cirrus-ci.com/v1/artifact/task/4536440638406656/log/src/test/regress/regression.diffs
> 
> Interesting.  I couldn't reproduce this locally, even across different 
> operating systems.  The cfbot failures appear to be sporadic, but also 
> happening across multiple systems, so it's clearly not just a local 
> environment failure.  Can anyone else perhaps reproduce this locally?

This patch set needed a rebase, so here it is.

About the sporadic test failure above, I think that is an existing issue 
that is just now exposed through some test timing changes.  The 
pg_get_expr() function used in information_schema.check_constraints has 
no locking against concurrent drops of tables.  I think in this 
particular case, the tests "domain" and "alter_table" are prone to this 
conflict.  If I move "domain" to a separate test group, the issue goes 
away.  I'll start a separate discussion about this issue.

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: table inheritance versus column compression and storage settings
Next
From: Peter Eisentraut
Date:
Subject: pg_get_expr locking