BUG #18171: Dropping an index on a partitioned table drops all child indices even with a restrict
The following bug has been logged on the website:
Bug reference: 18171
Logged by: Nick Dujay
Email address: nickdujay@gmail.com
PostgreSQL version: 12.8
Operating system: macOS
Description:
Here's the setup.
postgres=# create table parent (id bigserial, created_at timestamp not null
default now()) partition by range (created_at);
postgres=# create table child1 partition of parent for values from
('2019-01-01 00:00:00') TO ('2019-01-02 00:00:00');
postgres=# create index child_id_index on child1 (id);
postgres=# create index parent_id_index on parent (id);
postgres=# alter index parent_id_index attach partition child_id_index;
postgres=# \d parent
Partitioned table "public.parent"
Column | Type | Collation | Nullable |
Default
------------+-----------------------------+-----------+----------+------------------------------------
id | bigint | | not null |
nextval('parent_id_seq'::regclass)
created_at | timestamp without time zone | | not null | now()
Partition key: RANGE (created_at)
Indexes:
"parent_id_index" btree (id)
Number of partitions: 1 (Use \d+ to list them.)
postgres=# \d child1
Table "public.child1"
Column | Type | Collation | Nullable |
Default
------------+-----------------------------+-----------+----------+------------------------------------
id | bigint | | not null |
nextval('parent_id_seq'::regclass)
created_at | timestamp without time zone | | not null | now()
Partition of: parent FOR VALUES FROM ('2019-01-01 00:00:00') TO ('2019-01-02
00:00:00')
Indexes:
"child_id_index" btree (id)
When I attempt to drop the child index, I get an error.
postgres=# drop index concurrently child_id_index restrict;
ERROR: cannot drop index child_id_index because index parent_id_index
requires it
HINT: You can drop index parent_id_index instead.
When I attempt to drop the parent index concurrently, it fails
postgres=# drop index concurrently parent_id_index restrict;
ERROR: cannot drop partitioned index "parent_id_index" concurrently
I can drop the parent index without concurrently, but then it will take an
ACCESS EXCLUSIVE lock which I am trying to avoid.
postgres=# drop index parent_id_index;
DROP INDEX
postgres=# \d parent
Partitioned table "public.parent"
Column | Type | Collation | Nullable |
Default
------------+-----------------------------+-----------+----------+------------------------------------
id | bigint | | not null |
nextval('parent_id_seq'::regclass)
created_at | timestamp without time zone | | not null | now()
Partition key: RANGE (created_at)
Number of partitions: 1 (Use \d+ to list them.)
postgres=# \d child1
Table "public.child1"
Column | Type | Collation | Nullable |
Default
------------+-----------------------------+-----------+----------+------------------------------------
id | bigint | | not null |
nextval('parent_id_seq'::regclass)
created_at | timestamp without time zone | | not null | now()
Partition of: parent FOR VALUES FROM ('2019-01-01 00:00:00') TO ('2019-01-02
00:00:00')
This makes sense because the dependency is from the parent to the child, so
restrict is "correct".
I would like to be able to drop the parent index first without dropping the
child indices, and then drop all the child indices concurrently. Or vice
versa, drop the child indices concurrently first, and then drop the parent
index last.
On Thu, Oct 26, 2023 at 8:23 AM PG Bug reporting form <
noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 18171
Logged by: Nick Dujay
Email address: nickdujay@gmail.com
PostgreSQL version: 12.8
Operating system: macOS
Description:
Your examples below don't seem to match up with the subject line. And you
are using a two year old unsupported minor release of v12. And the
examples below don't indicate any kind of bug. If this really is a bug
report you should demonstrate that more succinctly, and upgrade to the
current supported release to see whether it has already been fixed.
If you are looking for general help on how to do things, or just want to
voice your disappointment regarding some unimplemented feature in v12, the
-general mailing list is the appropriate forum.
David J.
I first observed this on a production system running 15.3. I've re-run the
tests on 15.4 locally and produced the same result.
I realize in my original email that I didn't put restrict, so I've added
restrict and confirmed that the child indices are dropped.
postgres=# drop index parent_id_index restrict;
DROP INDEX
Would you consider this an unimplemented feature then, instead of a bug? If
so, i'll repost in general.
On Thu, 26 Oct 2023 at 11:33, David G. Johnston <david.g.johnston@gmail.com>
wrote:
Show quoted text
On Thu, Oct 26, 2023 at 8:23 AM PG Bug reporting form <
noreply@postgresql.org> wrote:The following bug has been logged on the website:
Bug reference: 18171
Logged by: Nick Dujay
Email address: nickdujay@gmail.com
PostgreSQL version: 12.8
Operating system: macOS
Description:Your examples below don't seem to match up with the subject line. And you
are using a two year old unsupported minor release of v12. And the
examples below don't indicate any kind of bug. If this really is a bug
report you should demonstrate that more succinctly, and upgrade to the
current supported release to see whether it has already been fixed.If you are looking for general help on how to do things, or just want to
voice your disappointment regarding some unimplemented feature in v12, the
-general mailing list is the appropriate forum.David J.
On Thu, Oct 26, 2023 at 9:17 AM Nicholas Dujay <nickdujay@gmail.com> wrote:
I first observed this on a production system running 15.3. I've re-run the
tests on 15.4 locally and produced the same result.I realize in my original email that I didn't put restrict, so I've added
restrict and confirmed that the child indices are dropped.postgres=# drop index parent_id_index restrict;
DROP INDEXWould you consider this an unimplemented feature then, instead of a bug?
If so, i'll repost in general.
I'd consider the subject line a bug, but probably at the documentation
level, not the code.
Reading the CREATE INDEX notes for partitioned tables it is clear that the
index created on the partitioned table is a single entity in the eyes of
the system. That it requires multiple objects to exist is an
implementation detail exposed during creation (i.e., the ONLY clause
resulting in an invalid index) but not during deletion.
DROP INDEX should have a Notes section where it makes this point explicitly
- namely while the children "depend" on the parent the type of dependence
is not the kind that is considered when evaluating RESTRICT.
In short, you do seem to have a specific complaint regarding the usability
of the system as is that belongs in -general. I would focus on the
problems the current behavior causes when you use the system as designed
and see what others suggest regarding workarounds or planned improvements
or whatnot.
David J.