Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit1d92a0c

Browse files
committed
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects hadserious problems:1. It did not verify that a drop cascading to a partition-child objectalso cascaded to at least one of the object's partition parents. Now,normally a child object would share all its dependencies with one oranother parent (e.g. a child index's opclass dependencies would be sharedwith the parent index), so that this oversight is usually harmless.But if some dependency failed to fit this pattern, the child could bedropped while all its parents remain, creating a logically brokensituation. (It's easy to construct artificial cases that break it,such as attaching an unrelated extension dependency to the child objectand then dropping the extension. I'm not sure if any less-artificialcases exist.)2. Management of partition dependencies during ATTACH/DETACH PARTITIONwas complicated and buggy; for example, after detaching a partitiontable it was possible to create cases where a formerly-child indexshould be dropped and was not, because the correct set of dependencieshad not been reconstructed.Less seriously, because multiple partition relationships wererepresented identically in pg_depend, there was an order-of-traversaldependency on which partition parent was cited in error messages.We also had some pre-existing order-of-traversal hazards for errormessages related to internal and extension dependencies. This iscosmetic to users but causes testing problems.Tofix#1, add a check at the end of the partition tree traversalto ensure that at least one partition parent got deleted. Tofix#2,establish a new policy that partition dependencies are in addition to,not instead of, a child object's usual dependencies; in this wayATTACH/DETACH PARTITION need not cope with adding or removing theusual dependencies.To fix the cosmetic problem, distinguish between primary and secondarypartition dependency entries in pg_depend, by giving them differentdeptypes. (They behave identically except for having differentpriorities for being cited in error messages.) This means that theformer 'I' dependency type is replaced with new 'P' and 'S' types.This also fixes a longstanding bug that after handling an internaldependency by recursing to the owning object, findDependentObjectsdid not verify that the current target was now scheduled for deletion,and did not apply the current recursion level's objflags to it.Perhaps that should be back-patched; but in the back branches itwould only matter if some concurrent transaction had removed theinternal-linkage pg_depend entry before the recursive call found it,or the recursive call somehow failed to find it, both of which seemunlikely.Catversion bump because the contents of pg_depend change forpartitioning relationships.Patch HEAD only. It's annoying that we're not fixing#2 in v11,but there seems no practical way to do so given that the problemis exactly a poor choice of what entries to put in pg_depend.We can't really fix that while staying compatible with what'sin pg_depend in existing v11 installations.Discussion:https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
1 parentc603b39 commit1d92a0c

File tree

12 files changed

+361
-180
lines changed

12 files changed

+361
-180
lines changed

‎doc/src/sgml/catalogs.sgml

Lines changed: 70 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -2970,7 +2970,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
29702970
referenced object, and should be automatically dropped
29712971
(regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal>
29722972
mode) if the referenced object is dropped. Example: a named
2973-
constraint on a table is madeautodependent on the table, so
2973+
constraint on a table is madeauto-dependent on the table, so
29742974
that it will go away if the table is dropped.
29752975
</para>
29762976
</listitem>
@@ -2982,38 +2982,61 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
29822982
<para>
29832983
The dependent object was created as part of creation of the
29842984
referenced object, and is really just a part of its internal
2985-
implementation. A <command>DROP</command> of the dependent object
2986-
will be disallowed outright (we'll tell the user to issue a
2987-
<command>DROP</command> against the referenced object, instead). A
2988-
<command>DROP</command> of the referenced object will be propagated
2989-
through to drop the dependent object whether
2990-
<command>CASCADE</command> is specified or not. Example: a trigger
2991-
that's created to enforce a foreign-key constraint is made
2992-
internally dependent on the constraint's
2993-
<structname>pg_constraint</structname> entry.
2985+
implementation. A direct <command>DROP</command> of the dependent
2986+
object will be disallowed outright (we'll tell the user to issue
2987+
a <command>DROP</command> against the referenced object, instead).
2988+
A <command>DROP</command> of the referenced object will result in
2989+
automatically dropping the dependent object
2990+
whether <literal>CASCADE</literal> is specified or not. If the
2991+
dependent object is reached due to a dependency on some other object,
2992+
the drop is converted to a drop of the referenced object, so
2993+
that <literal>NORMAL</literal> and <literal>AUTO</literal>
2994+
dependencies of the dependent object behave much like they were
2995+
dependencies of the referenced object.
2996+
Example: a view's <literal>ON SELECT</literal> rule is made
2997+
internally dependent on the view, preventing it from being dropped
2998+
while the view remains. Dependencies of the rule (such as tables it
2999+
refers to) act as if they were dependencies of the view.
29943000
</para>
29953001
</listitem>
29963002
</varlistentry>
29973003

29983004
<varlistentry>
2999-
<term><symbol>DEPENDENCY_INTERNAL_AUTO</symbol> (<literal>I</literal>)</term>
3005+
<term><symbol>DEPENDENCY_PARTITION_PRI</symbol> (<literal>P</literal>)</term>
3006+
<term><symbol>DEPENDENCY_PARTITION_SEC</symbol> (<literal>S</literal>)</term>
30003007
<listitem>
30013008
<para>
30023009
The dependent object was created as part of creation of the
30033010
referenced object, and is really just a part of its internal
3004-
implementation. A <command>DROP</command> of the dependent object
3005-
will be disallowed outright (we'll tell the user to issue a
3006-
<command>DROP</command> against the referenced object, instead).
3007-
While a regular internal dependency will prevent
3008-
the dependent object from being dropped while any such dependencies
3009-
remain, <literal>DEPENDENCY_INTERNAL_AUTO</literal> will allow such
3010-
a drop as long as the object can be found by following any of such
3011+
implementation; however, unlike <literal>INTERNAL</literal>,
3012+
there is more than one such referenced object. The dependent object
3013+
must not be dropped unless at least one of these referenced objects
3014+
is dropped; if any one is, the dependent object should be dropped
3015+
whether or not <literal>CASCADE</literal> is specified. Also
3016+
unlike <literal>INTERNAL</literal>, a drop of some other object
3017+
that the dependent object depends on does not result in automatic
3018+
deletion of any partition-referenced object. Hence, if the drop
3019+
does not cascade to at least one of these objects via some other
3020+
path, it will be refused. (In most cases, the dependent object
3021+
shares all its non-partition dependencies with at least one
3022+
partition-referenced object, so that this restriction does not
3023+
result in blocking any cascaded delete.)
3024+
Primary and secondary partition dependencies behave identically
3025+
except that the primary dependency is preferred for use in error
3026+
messages; hence, a partition-dependent object should have one
3027+
primary partition dependency and one or more secondary partition
30113028
dependencies.
3012-
Example: an index on a partition is made internal-auto-dependent on
3013-
both the partition itself as well as on the index on the parent
3014-
partitioned table; so the partition index is dropped together with
3015-
either the partition it indexes, or with the parent index it is
3016-
attached to.
3029+
Note that partition dependencies are made in addition to, not
3030+
instead of, any dependencies the object would normally have. This
3031+
simplifies <command>ATTACH/DETACH PARTITION</command> operations:
3032+
the partition dependencies need only be added or removed.
3033+
Example: a child partitioned index is made partition-dependent
3034+
on both the partition table it is on and the parent partitioned
3035+
index, so that it goes away if either of those is dropped, but
3036+
not otherwise. The dependency on the parent index is primary,
3037+
so that if the user tries to drop the child partitioned index,
3038+
the error message will suggest dropping the parent index instead
3039+
(not the table).
30173040
</para>
30183041
</listitem>
30193042
</varlistentry>
@@ -3026,9 +3049,10 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
30263049
the referenced object (see
30273050
<link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>).
30283051
The dependent object can be dropped only via
3029-
<command>DROP EXTENSION</command> on the referenced object. Functionally
3030-
this dependency type acts the same as an internal dependency, but
3031-
it's kept separate for clarity and to simplify <application>pg_dump</application>.
3052+
<command>DROP EXTENSION</command> on the referenced object.
3053+
Functionally this dependency type acts the same as
3054+
an <literal>INTERNAL</literal> dependency, but it's kept separate for
3055+
clarity and to simplify <application>pg_dump</application>.
30323056
</para>
30333057
</listitem>
30343058
</varlistentry>
@@ -3038,10 +3062,13 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
30383062
<listitem>
30393063
<para>
30403064
The dependent object is not a member of the extension that is the
3041-
referenced object (and so should not be ignored by pg_dump), but
3042-
cannot function without it and should be dropped when the
3043-
extension itself is. The dependent object may be dropped on its
3044-
own as well.
3065+
referenced object (and so it should not be ignored
3066+
by <application>pg_dump</application>), but it cannot function
3067+
without the extension and should be auto-dropped if the extension is.
3068+
The dependent object may be dropped on its own as well.
3069+
Functionally this dependency type acts the same as
3070+
an <literal>AUTO</literal> dependency, but it's kept separate for
3071+
clarity and to simplify <application>pg_dump</application>.
30453072
</para>
30463073
</listitem>
30473074
</varlistentry>
@@ -3063,6 +3090,19 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
30633090
Other dependency flavors might be needed in future.
30643091
</para>
30653092

3093+
<para>
3094+
Note that it's quite possible for two objects to be linked by more than
3095+
one <structname>pg_depend</structname> entry. For example, a child
3096+
partitioned index would have both a partition-type dependency on its
3097+
associated partition table, and an auto dependency on each column of
3098+
that table that it indexes. This sort of situation expresses the union
3099+
of multiple dependency semantics. A dependent object can be dropped
3100+
without <literal>CASCADE</literal> if any of its dependencies satisfies
3101+
its condition for automatic dropping. Conversely, all the
3102+
dependencies' restrictions about which objects must be dropped together
3103+
must be satisfied.
3104+
</para>
3105+
30663106
</sect1>
30673107

30683108

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp