Re: LOCK TABLE and DROP TABLE on temp tables of other sessions

On Fri, Feb 14, 2020 at 05:59:34PM +0530, Ashutosh Bapat wrote:
> On Fri, Feb 14, 2020 at 11:35 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> One thing that we need to consider is if there are applications which
>> take advantage of LOCK allowed on temp relations from other backends
>> or not. One downside is that if one backend takes a lock on a temp
>> table from a different session, then this other session would not
>> completely shut down (still report the shutdown to the client),
>> and would remain blocked during the temp schema cleanup until the
>> transaction of the session locking the temp relation commits. This
>> blocks access to one connection slot, still we are talking about an
>> operation where the owner of the temp schema wants to do the lock.
>
> That might be disastrous if happens by accident eating up most of the
> available connection slots.

Well, that would be an owner doing that.

> Whatever the user wants to achieve using LOCK [temp] TABLE of other
> session, I guess can be achieved by other means or can be shown to have
> disastrous effect. So that kind of usage pattern would better be forced to
> change.

Anyway, don't take me wrong. I would be rather in favor of
restricting LOCK but that does not seem like something enough for a
backpatch. One recent example in this area I had to deal with is
REINDEX on temp tables. We have some assumptions which involve lock
upgrades (ShareUpdateExclusiveLock => AccessExclusiveLock between the
moment we take the relation lock using its RangeVar until the moment
the reindex is actually done), so being able to take a conflicting
lock on the temp relation could cause reindex to deadlock.
--
Michael