Re: ATTACH/DETACH PARTITION CONCURRENTLY - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ATTACH/DETACH PARTITION CONCURRENTLY
Date
Msg-id CA+Tgmob1uEiN06Qkngw+1DypPyRB5j=W+yXoVxozws39OAaveQ@mail.gmail.com
Whole thread Raw
In response to Re: ATTACH/DETACH PARTITION CONCURRENTLY  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: ATTACH/DETACH PARTITION CONCURRENTLY  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Dec 20, 2018 at 4:11 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Oh, so maybe this case is already handled by plan invalidation -- I
> mean, if we run DDL, the stored plan is thrown away and a new one
> recomputed.  IOW this was already a solved problem and I didn't need to
> spend effort on it. /me slaps own forehead

I'm kinda saying the opposite - I'm not sure that it's safe even with
the higher lock levels.  If the plan is relying on the same partition
descriptor being in effect at plan time as at execution time, that
sounds kinda dangerous to me.

Lowering the lock level might also make something that was previously
safe into something unsafe, because now there's no longer a guarantee
that invalidation messages are received soon enough. With
AccessExclusiveLock, we'll send invalidation messages before releasing
the lock, and other processes will acquire the lock and then
AcceptInvalidationMessages().  But with ShareUpdateExclusiveLock the
locks can coexist, so now there might be trouble.  I think this is an
area where we need to do some more investigation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ATTACH/DETACH PARTITION CONCURRENTLY
Next
From: Alvaro Herrera
Date:
Subject: monitoring CREATE INDEX [CONCURRENTLY]