Re: ALTER TABLE ALTER COLUMN SET TYPE crash

On Tue, Aug 25, 2020 at 01:35:11PM -0400, Bruce Momjian wrote:
> 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.

There are already some safeguards to prevent directly the use of
aggregates in USING, and here we have a function that itself calls an
aggregate on the table.

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

Hmm. That's not an easy problem as this would need restrictions for
high-level commands directly in the executor.. And it is not like you
should restrict everything either.
--
Michael