pgsql: Fix relcache handling of the 'default' partition
От | Alvaro Herrera |
---|---|
Тема | pgsql: Fix relcache handling of the 'default' partition |
Дата | |
Msg-id | E1eyfHj-00005w-Dc@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Fix relcache handling of the 'default' partition My commit 4dba331cb3dc that moved around CommandCounterIncrement calls in partitioning DDL code unearthed a problem with the relcache handling for the 'default' partition: the construction of a correct relcache entry for the partitioned table was at the mercy of lack of CCI calls in non-trivial amounts of code. This was prone to creating problems later on, as the code develops. This was visible as a test failure in a compile with RELCACHE_FORCE_RELASE (buildfarm member prion). The problem is that after the mentioned commit it was possible to create a relcache entry that had incomplete information regarding the default partition because I introduced a CCI between adding the catalog entries for the default partition (StorePartitionBound) and the update of pg_partitioned_table entry for its parent partitioned table (update_default_partition_oid). It seems the best fix is to move the latter so that it occurs inside the former; the purposeful lack of intervening CCI should be more obvious, and harder to break. I also remove a check in RelationBuildPartitionDesc that returns NULL if the key is not set. I couldn't find any place that needs this hack anymore; probably it was required because of bugs that have since been fixed. Fix a few typos I noticed while reviewing the code involved. Discussion: https://postgr.es/m/20180320182659.nyzn3vqtjbbtfgwq@alvherre.pgsql Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/56163004b8b2151db279744b77138d4d90e2d5cb Modified Files -------------- src/backend/catalog/heap.c | 16 ++++++++++++++-- src/backend/catalog/partition.c | 7 ------- src/backend/commands/tablecmds.c | 25 +++++++------------------ 3 files changed, 21 insertions(+), 27 deletions(-)
В списке pgsql-committers по дате отправления: