On Thu, Aug 10, 2017 at 8:00 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > Attached patches with the comments addressed.
I have committed 0001-0003 as 480f1f4329f1bf8bfbbcda8ed233851e1b110ad4 and e139f1953f29db245f60a7acb72fccb1e05d2442. 0004 doesn't apply any more, probably due to commit d57929afc7063431f80a0ac4c510fc39aacd22e6. I think something along these lines could be separately committed prior to the main patch, and I think that would be a good idea just to flush out any bugs in this part independently of the rest. However, I also think that we probably ought to try to get Amit Langote's changes to this function to repair the locking order and expand in bound order committed before proceeding with these changes. In fact, I think there's a certain amount of conflict between what's being discussed over there and what you're trying to do here. In that thread, we propose to move partitioned tables at any level to the front of the inheritance expansion. Here, however, you want to expand level by level. I think partitioned-tables-first is the right approach for the reasons discussed on the other thread; namely, we want to be able to prune leaf partitions before expanding them, but that requires us to expand all the non-leaf tables first to maintain a consistent locking order in all scenarios. So the approach you've taken in this patch may need to be re-thought somewhat. -- 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
