Re: ATTACH/DETACH PARTITION CONCURRENTLY

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: ATTACH/DETACH PARTITION CONCURRENTLY
Date: 2018-11-21 18:37:21
Message-ID: CA+TgmoYTryEphewvhYT2_jdGRnzuF3622QBJHGTbQBV7Rq__Zw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 14, 2018 at 9:03 PM Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2018/11/15 4:27, Robert Haas wrote:
> > RelationBuildPartitionDesc doesn't lock the children
> > whose relpartbounds it is fetching (!), so unless we're guaranteed to
> > have already locked them children earlier for some other reason, we
> > could grab the partition bound at this point and then it could change
> > again before we get a lock on them.
>
> Hmm, I think that RelationBuildPartitionDesc doesn't need to lock a
> partition before fetching its relpartbound, because the latter can't
> change if the caller is holding a lock on the parent, which it must be if
> we're in RelationBuildPartitionDesc for parent at all. Am I missing
> something?

After thinking about this for a bit, I think that right now it's fine,
because you can't create or drop or attach or detach a partition
without holding AccessExclusiveLock on both the parent and the child,
so if you hold even AccessShareLock on the parent, the child's
relpartbound can't be changing. However, what we want to do is get
the lock level on the parent down to ShareUpdateExclusiveLock, at
which point the child's relpartbound could indeed change under us. I
think, however, that what I previously posted as 0002 is sufficient to
fix that part of the problem.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-11-21 18:51:03 Re: pgsql: instr_time.h: add INSTR_TIME_SET_CURRENT_LAZY
Previous Message Andres Freund 2018-11-21 18:36:42 Re: [RFC] Removing "magic" oids