Re: ALTER TABLE ALTER COLUMN SET TYPE crash - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: ALTER TABLE ALTER COLUMN SET TYPE crash
Date
Msg-id 20200825173511.GA20679@momjian.us
Whole thread Raw
In response to Re: ALTER TABLE ALTER COLUMN SET TYPE crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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




pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ALTER COLUMN SET TYPE crash
Next
From: PG Bug reporting form
Date:
Subject: BUG #16592: websearch_to_tsquery() returns queries that don't result in expected matches