Re: pg_get_expr locking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_get_expr locking
Date: 2024-02-07 15:26:30
Message-ID: 789503.1707319590@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2024-02-07 15:30:00 Re: Printing backtrace of postgres processes
Previous Message just madhu 2024-02-07 15:23:20 Re: pgjdbc is not working with PKCS8 certificates with password