Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, Jul 25, 2019 at 03:41:05PM -0400, Stephen Frost wrote:
> > Greetings,
> >
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > After talking to Joe Conway, I just want to mention that if we decide
> > > that the LSN is unique among heap and index, or among heap or index, we
> > > will need to make sure future WAL records retain this uniqueness.
> >
> > One thing comes to mind regarding this and I'll admit that I don't quite
> > remember exactly off-hand but I also don't want to not mention it now
> > and forget to later.
> >
> > What about pg_upgrade?
>
> So, we don't carry WAL from the old cluster to the new cluster, so if
> the WAL is changed and had duplicates, it would only be new WAL records.
Right, we don't carry it forward- but what I couldn't remember is if
start from more-or-less LSN 0 or if pg_upgrade will arrange it such that
the new major version will start from LSN-of-old+1 (or whatever). Seems
like it'd *have* to be the latter, but just thought of it and wanted to
make sure.
> pg_upgrade seems immune to must of this, and that is by design.
> However, I am hesitant to change the heap/index page format for
> encryption because if we add fields, old pages might not fit as
> encrypted pages, and then you have to move rows around, and things
> become _much_ more complicated.
Yeah, I'm afraid we are going to have a hard time making this work
without changing the page format for encrypted.. I don't know if that's
actually a *huge* issue like we've considered it to be in the past or
not, as making someone rewrite just the few sensitive tables in their
environment might not be that bad, and there's also logical replication
today..
> I don't see any other pg_upgrade issues, unless someone else does. Oh,
> we will have to check pg_control for a matching encryption format.
Yes, certainly it'd need to be updated for at least that, when upgading
an encrypted cluster.
Thanks!
Stephen