On 2024-Oct-25, Alexander Lakhin wrote:
> I've also discovered another anomaly with a similar setup, but it's not
> related to 53af9491a.
Hmm, it may well be a preexisting problem, but I do think it involves
the same code. As far as I can tell, the value "2" here
> This script ends up with:
> ERROR: invalid attribute number 2
> ERROR: cache lookup failed for attribute 2 of relation 16398
is coming from riinfo->confdelsetcols which was set up by
DetachPartitionFinalize during the last DETACH operation.
Hmm, actually, the confdelsetcols before detach and after detach is always {2}, as below:
postgres=# select oid, conname, conrelid,conparentid,confdelsetcols from pg_constraint where conrelid = 16397;
oid | conname | conrelid | conparentid | confdelsetcols
-------+-----------+----------+-------------+----------------
16400 | pt_a_fkey | 16397 | 16392 | {2}
(1 row)
postgres=# ALTER TABLE pt DETACH PARTITION tp1;
ALTER TABLE
postgres=# select oid, conname, conrelid,conparentid,confdelsetcols from pg_constraint where conrelid = 16397;
oid | conname | conrelid | conparentid | confdelsetcols
-------+-----------+----------+-------------+----------------
16400 | pt_a_fkey | 16397 | 0 | {2}
(1 row)
Even though no detach, the confdelsetcols is {2} . But no error report. Because the rel->rd_att->natts of pt is 2.
It will not go into tp1 because tp1 is a partition of pt. But after detach, the rel->rd_att->natts of tp1 is 1,
so "ERROR: invalid attribute number 2" will report.
CREATE TABLE tp1... will ignore the dropped column of parent, so the natts of tp1 is 1, but its parent is 2.
