Re: BUG #18618: pg_upgrade from 14 to 15+ fails for unlogged table with identity column

I wrote:
> However, in binary-upgrade mode there seems little need to be
> concerned about whether we produce a nice WAL trace of the SET LOGGED
> operation. I think we can just summarily change the sequence's
> relpersistence field and be done with it, more or less as attached.

Nope, after further testing that doesn't work at all. In the first
place, the SET UNLOGGED case falls foul of some assertions in
the relcache code having to do with WAL-skipping; and that code looks
complex and fragile enough that I don't want to try to poke holes
in it. In the second place, I'd forgotten the need to add or remove
an init fork.

> The only alternative I can see is to extend the ALTER TABLE ADD
> GENERATED syntax to allow correct specification of the sequence's
> LOGGED/UNLOGGED status to begin with. While cleaner, that would be
> a lot more work and probably result in compatibility problems for
> normal uses of pg_dump (where the output might get loaded into a
> server version that lacks the syntax extension).

So we have to do it like that, and it seems not that bad, especially
if we follow the lead of the SEQUENCE NAME option and don't bother
to document this stuff. (I don't think that's a great precedent,
but I didn't change it here.)

Looking at this draft patch a second time, one way that we could
reduce the surface area for compatibility problems is to emit these
new ADD GENERATED options only in binary-upgrade mode, and continue to
use ALTER SEQUENCE SET in standard dumps. But I kind of think that
it's not worth the complication: sequences that don't match their
table's persistence must be quite rare, else we'd have heard about
this problem long ago.

regards, tom lane