| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Virender Singla <virender(dot)cse(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Aniket Jha <aniketkumarj(at)gmail(dot)com> |
| Subject: | Re: Major Version Upgrade failure due to orphan roles entries in catalog |
| Date: | 2026-02-25 16:50:16 |
| Message-ID: | 265501.1772038216@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> In v16+, if the grantor is not valid, that's unexpected and something
> has gone wrong, perhaps due to insufficient locking, or maybe due to
> catalog corruption. The warning is a fair response to a
> seemingly-corrupted catalog state. But in v15-, this is just business
> as usual; there's no particular expectation that the grantor must be a
> valid role OID, and IMHO the best thing to do is give the same result
> that a pre-v16 pg_dumpall would have produced.
I don't entirely agree that it's "business as usual": somebody screwed
up to get the database into that state. I'm not here to apportion
blame for that between the user and the database, but I do think it's
appropriate for pg_dumpall to complain that it's facing invalid data.
If you're good with pg_dumpall producing a warning and then emitting
the GRANT with no grantor clause, I will go make that happen.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-02-25 16:57:59 | Re: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change |
| Previous Message | Vishal Prasanna | 2026-02-25 16:32:54 | RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change |