Re: LOCK TABLE and DROP TABLE on temp tables of other sessions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: LOCK TABLE and DROP TABLE on temp tables of other sessions
Date
Msg-id 20200218042836.GF4176@paquier.xyz
Whole thread Raw
In response to Re: LOCK TABLE and DROP TABLE on temp tables of other sessions  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
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@paquier.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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Flexible pglz_stategy values and delete const.
Next
From: Amit Langote
Date:
Subject: Re: plan cache overhead on plpgsql expression