pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Make getObjectDescription robust against dangling amproc type li 6+ messages / 1 participants [nested] [flat]
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/531cbd8b74a574df51549ec378e046be23d4c391 Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c82003760d747a64f2decd9664a766485f66121a Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d9d5e1b48e0db25961e108a13acb616a4911ee29 Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/faad0183507b9185382b0ab6f7701144b8cc5687 Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5b44a317ae031de76989be98871cd1e67c1669e4 Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make getObjectDescription robust against dangling amproc type li @ 2024-12-07 20:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-12-07 20:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make getObjectDescription robust against dangling amproc type links. Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d401914679dea7e14536a9444bee0742c7de4f2f Modified Files -------------- src/backend/catalog/objectaddress.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-12-07 20:56 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us> 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us> 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us> 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us> 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us> 2024-12-07 20:56 pgsql: Make getObjectDescription robust against dangling amproc type li Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox