| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | postgresql(at)blakeslee(dot)uk |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Subject: | Re: BUG #18562: pg_upgrade (14.12 -> 15.7/16.3) fails when schema has unlogged table with logged sequence |
| Date: | 2024-08-01 14:23:04 |
| Message-ID: | 3736990.1722522184@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I am seeing a recurring failure when attempting to run pg_upgrade on a 14.12
> database when targeting 15.7 or 16.3.
> I've found this error to occur whenever the schema contains an unlogged
> table with a logged sequence.
Yeah, the way that pg_dump tries to set this situation up is to create
the sequence by using ALTER COLUMN ADD GENERATED, and then change
the sequence's logged-ness. That cannot work in binary-upgrade mode.
Before we think about alternative ways to dump it though, I wonder
why we permit such a situation at all. It doesn't seem like a
well-considered bit of database design for an identity sequence's
logged-ness to differ from the owning table's.
The combination of logged table and unlogged sequence is surely a
foot-gun, even if you think there's some value in the other way.
But we allow both.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2024-08-01 16:25:19 | BUG #18563: Where is tha "FIRST" aggregate function?? |
| Previous Message | PG Bug reporting form | 2024-08-01 11:35:46 | BUG #18562: pg_upgrade (14.12 -> 15.7/16.3) fails when schema has unlogged table with logged sequence |