public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Don't try to record dependency on a dropped column's datatype
6+ messages / 1 participants
[nested] [flat]
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/fd93ee100830a1c0f4d292addd0a460cb48106a0
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f9d5a52da4ca71d592e9cef55ed676136362b8b5
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/c1588f92a915f4af890c70c66891a40ee23588b4
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d44cd467471c8977605eff7e9ef7535dc23dcff7
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/ef3d7b15e4cd075b4e7f036ba151055d650b33c6
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to record dependency on a dropped column's datatype
@ 2026-05-27 15:50 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-05-27 15:50 UTC (permalink / raw)
To: [email protected]
Don't try to record dependency on a dropped column's datatype
When creating a relation with a dropped column, we called
recordDependencyOn() also on the datatype of the dropped column, which
is always InvalidOid. In versions 15 and above, that was harmless
because recordDependencyOn() considers InvalidOid as a pinned object,
and skips over it. On version 14, isPinnedObject() does not consider
InvalidOid as pinned, so we created a bogus pg_depend entry with
refobjectid == 0.
As far as I can tell, the only case when AddNewAttributeTuples() is
called with dropped columns is when performing a table-rewriting ALTER
TABLE command. That temporarily creates a new relation with the same
columns, including dropped ones, then swaps the relations, and drops
the newly created table again. So even on version 14, the bogus
pg_depend entry was only on the transient relation that was dropped at
the end of the ALTER TABLE command, which was harmless.
Even though this is harmless, let's be tidy, similar to commit
713bce9484. The reason I noticed this now and why I backported this,
is because the next commit will add code to acquire locks on the
referenced objects, and we don't want to acquire a lock on InvalidOid.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/36b6ed2606e18066ca1ae95d877aef8e98fad31d
Modified Files
--------------
src/backend/catalog/heap.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-27 15:50 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
2026-05-27 15:50 pgsql: Don't try to record dependency on a dropped column's datatype Heikki Linnakangas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox