Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Aug 16, 2024 at 8:36 AM Amit Langote <amitlangot...@gmail.com> wrote:
>> So it is possible for the executor to try to run a plan that has
>> become invalid since it was created, so...
> I'm not sure what the "so what" here is.
The fact that there are holes in our protections against that doesn't
make it a good idea to walk away from the protections. That path
leads to crashes and data corruption and unhappy users.
What the examples here are showing is that AcquireExecutorLocks
is incomplete because it only provides defenses against DDL
initiated by other sessions, not by our own session. We have
CheckTableNotInUse but I'm not sure if it could be applied here.
We certainly aren't calling that in anywhere near as systematic
a way as we have for acquiring locks.
Maybe we should rethink the principle that a session's locks
never conflict against itself, although I fear that might be
a nasty can of worms.
Could it work to do CheckTableNotInUse when acquiring an
exclusive table lock? I don't doubt that we'd have to fix some
code paths, but if the damage isn't extensive then that
might offer a more nearly bulletproof approach.
regards, tom lane
