Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Jul 25, 2019 at 03:41:05PM -0400, Stephen Frost wrote: > > Greetings, > > > > * Bruce Momjian (br...@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
signature.asc
Description: PGP signature
