Re: ATTACH/DETACH PARTITION CONCURRENTLY

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ATTACH/DETACH PARTITION CONCURRENTLY
Дата
Msg-id CA+Tgmob1uEiN06Qkngw+1DypPyRB5j=W+yXoVxozws39OAaveQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ATTACH/DETACH PARTITION CONCURRENTLY  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: ATTACH/DETACH PARTITION CONCURRENTLY  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: ATTACH/DETACH PARTITION CONCURRENTLY
Следующее
От: Alvaro Herrera
Дата:
Сообщение: monitoring CREATE INDEX [CONCURRENTLY]