On Fri, Feb 14, 2020 at 05:59:34PM +0530, Ashutosh Bapat wrote: > On Fri, Feb 14, 2020 at 11:35 AM Michael Paquier <mich...@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
signature.asc
Description: PGP signature
