Peter Eisentraut <peter@eisentraut.org> 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) case of this being
> discussed at [0]. I also see various mentions of this issue in the
> commit logs, mostly related to pg_dump.
> Is there a reason there is no locking? Performance?
I think we have a general rule that you shouldn't be able to take
locks on relations you have no privileges for, so pg_get_expr would
need to verify privileges if it locked the rel. At least for
pg_dump's purposes, that cure would be about as bad as the disease.
> 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?
regards, tom lane
