I wrote:
> Peter Eisentraut writes:
>> I think the situation is that one test (domain) runs pg_get_expr as part
>> of an information_schema view, while at the same time another test
>> (alter_table) drops a table that the pg_get_expr is just processing.
> The test case that's failing is, IIUC,
Peter Eisentraut writes:
> On 07.02.24 16:26, Tom Lane wrote:
>> Why would a test be applying pg_get_expr to a table it doesn't
>> control?
> I think the situation is that one test (domain) runs pg_get_expr as part
> of an information_schema view, while at the same time another test
> (alter_ta
On 07.02.24 16:26, Tom Lane wrote:
What workaround should we use if there are conflicts created by
concurrent regression tests? Just move the tests around a bit until the
issue goes away?
Why would a test be applying pg_get_expr to a table it doesn't
control?
I think the situation is that on
Peter Eisentraut writes:
> The function pg_get_expr(), which is used in various system views and
> information schema views, does not appear to lock the table passed as
> the second argument, and so appears to be liable to fail if there is a
> concurrent drop of the table. There is a (probable
The function pg_get_expr(), which is used in various system views and
information schema views, does not appear to lock the table passed as
the second argument, and so appears to be liable to fail if there is a
concurrent drop of the table. There is a (probable) case of this being
discussed at
