We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't conflict the lock only blocks use
of the table by other sessions, not our own. Without this check,
the ALTER might confuse the outer SQL command since any previous
inspection of the table would potentially become invalid.
However, the RelisBecomingView code path in DefineQueryRewrite never
got that memo, and assumed that AccessExclusiveLock is sufficient
for performing something morally equivalent to a rather invasive
ALTER TABLE. Unsurprisingly, this can confuse an outer command
that is trying to do something with the table.
This was submitted as a security issue, but the security team
has been unable to identify any consequence worse than a null
pointer dereference (from trying to access rd_tableam methods
that the relation no longer has). Therefore, in accordance
with our usual policy, it's not security material and should
just be fixed as a routine bug.
Fix by disallowing the operation if the table is open locally,
exactly as ALTER TABLE does it.
Per an anonymous security researcher, via Bundesamt für Sicherheit
in der Informationstechnik.
Patch v12-v15 only. In v16 and later, we removed this code
altogether (cf. commit b23cd185f), so that there's no issue.
1ee22d1e87