Re: ALTER TABLE ALTER COLUMN SET TYPE crash

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Tue, Aug 25, 2020 at 03:05:11PM +0900, Michael Paquier wrote:
>> On Tue, Aug 25, 2020 at 02:14:06PM +1000, Robins Tharakan wrote:
>>> Unlike a recently reported similar issue, executing the following ALTER
>>> TABLE on the regression database crashes Postgres (master).

>> Such reports are constructive! I can reproduce the crash here down to
>> 9.5. From what I can see, the problem comes from ATRewriteTable() ->
>> ExecEvalExpr() when we evaluate expressions with inputs coming from
>> the old tuple. It looks like a memory corruption issue or a context
>> issue at quick glance, and I cannot get a clean backtrace.

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.

regards, tom lane