On Wed, Nov 14, 2018 at 9:03 PM Amit Langote
<Langote_Amit_f8@lab.ntt.co.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
