| From: | solai v <solai(dot)cdac(at)gmail(dot)com> |
|---|---|
| To: | Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> |
| Cc: | Rui Zhao <zhaorui126(at)gmail(dot)com>, Laurenz Albe <laur(at)aon(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table |
| Date: | 2026-08-07 07:06:28 |
| Message-ID: | CAF0whuft4HjO1NhMuir-fJ-mcAWbX5m4ZG7FuARcLuxJzgK2_Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
I went through the reproduction steps discussed in this thread using
PostgreSQL 20devel with the pg_stat_statements extension.
The workflow I tested was:
- Created the benchmark_owner role and a database owned by it.
- Connected to the database as benchmark_owner and created the
pg_stat_statements extension.
- Verified that the expected entries were created in pg_init_privs.
- Executed REASSIGN OWNED, DROP OWNED, and then dropped the
benchmark_owner role.
- Finally, checked for orphan entries in pg_init_privs using the query
shared in this discussion.
In my testing, the final query returned:
(0 rows)
So I was not able to reproduce the orphan pg_init_privs entries on
PostgreSQL 20devel.
This seems to be consistent with Tom Lane's earlier comment that the
orphaned-row problem should not exist in PostgreSQL 17 and later.
Thanks for the detailed reproduction steps .They were helpful in
understanding and testing the workflow.
Regards,
solai
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-08-07 08:41:21 | Re: BUG #19610: Database won't start if an unrelated process is exist |
| Previous Message | Michael Paquier | 2026-08-07 06:34:38 | Re: PostgreSQL 18.4 backend SIGSEGV in pgstat_gc_entry_refs() after caught DSM attach error |