Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: huseyin.d3r@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2026-06-07T15:51:59Z
Lists: pgsql-bugs
Greg Sabino Mullane <htamfids@gmail.com> writes: >> 5. Verify orphan records remain in pg_init_privs: > Thanks for providing a failing use case. I ran this on a 18.3 server and > found no orphaned rows - but I used the pg_stat_statements extension > instead of pg_wait_sampling. Could you try your experiment using > pg_stat_statements? And could you also show us the contents of the errant > rows in pg_init_privs for the failing case? The orphaned-rows problem shouldn't exist in v17 and later (see 534287403, 35dd40d34, and related commits). The OP is apparently complaining about an upgrade from v14, where such rows could exist. I don't especially care for the proposed fix of making pg_upgrade refuse to run. Manually correcting such situations would be tedious and error-prone. Plus, it's inconsistent with what we did about related issues with role GRANTs (see 29d75b25b and 74b4438a7). I wonder if it'd be sane for pg_dump to just skip dangling role references in pg_init_privs. regards, tom lane