On Fri, Aug 26, 2016 at 1:33 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > We do take a lock on the parent because we would be changing its partition > descriptor (relcache). I changed MergeAttributes() such that an > AccessExclusiveLock instead of ShareUpdateExclusiveLock is taken if the > parent is a partitioned table.
Hmm, that seems both good and bad. On the good side, as mentioned, being able to rely on the partition descriptor not changing under us makes this sort of thing much easier to reason about. On the bad side, it isn't good for this feature to have worse concurrency than regular inheritance. Not sure what to do about this. > If we need an AccessExclusiveLock on parent to add/remove a partition > (IOW, changing that child table's partitioning information), then do we > need to lock the individual partitions when reading partition's > information? I mean to ask why the simple syscache look-ups to get each > partition's bound wouldn't do. Well, if X can't be changed without having an AccessExclusiveLock on the parent, then an AccessShareLock on the parent is sufficient to read X, right? Because those lock modes conflict. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers