Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > I was toying with a couple of ideas that would involve changing the > storage of sequences. (Say, for the sake of discussion, removing the > problematic/useless sequence_name field.) This would cause problems for > pg_upgrade, because pg_upgrade copies the "heap" storage of sequences > like it does for normal tables, and we have no facilities for effecting > any changes during that.
> There was a previous discussion in the early days of pg_migrator, which > resulted in the current behavior: > https://www.postgresql.org/message-id/flat/20090713220112.GF7933%40klana.box > This also alluded to what I think was the last change in the sequence > storage format (10a3471bed7b57fb986a5be8afdee5f0dda419de) between > versions 8.3 and 8.4. How did pg_upgrade handle that? I think it probably never did handle that. pg_upgrade doesn't currently claim to support migrating from 8.3, and the thread you mention shows that the original attempt at 8.3->8.4 migration crashed-and-burned for numerous unrelated reasons. We may not have ever got to the point of noticing that 10a3471be also created a problem. > I think the other solution mentioned in that thread would also work: > Have pg_upgrade treat sequences more like system catalogs, whose format > changes between major releases, and transferred them via the > dump/restore route. So instead of copying the disk files, issue a > setval call, and the sequence should be all set up. Seems reasonable. If you're proposing to expose --sequence-data as a user-visible option, the patch set lacks documentation. But I wonder whether it shouldn't simply be a side-effect of --binary-upgrade. It seems a tad non-orthogonal for a user switch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
