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
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 |