On Tue, Aug 25, 2020 at 12:14:20PM -0400, Tom Lane wrote:
> I think the nature of the problem (and Robins' other report too) is pretty
> clear. We have a SQL or plpgsql function that's trying to access a table
> that is inconsistent during an ALTER TABLE operation. The function would
> be locked out from seeing that transient state if it were in another
> session, thanks to normal locking rules; but the lock acquisition rules
> don't prevent same-session accesses.
>
> ALTER TABLE and related utility commands contain guards against the
> reverse form of this problem: CheckTableNotInUse will bitch if there's
> some already-active outer query referencing the table. But we haven't
> thought about the possibility of one of these commands executing
> user-defined code midway through.
That does explain why it fails on the _second_ time through those
lower-level functions.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
