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
