On Tue, Apr 9, 2019 at 12:14 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> It's more doable here than elsewhere because the data on disk isn't
> persistent across server restart, let alone pg_upgrade. Let's see...
> each segment file is 256kb and we need to be able to address 2^64 *
> sizeof(SerCommitSequenceNumber), so you'd have segment files numbered
> from 0 up to 1ffffffffffff (so you'd need slru.c to support 13 char
> segment names and 64 bit segment numbers, whereas it currently has a
> limit of 6 in SlruScanDirectory and uses int for segment number).
Come to think of it, even for the persistent ones, pg_upgrade could
rename them to a new scheme anyway as long as the segment size remains
the same. I'd be inclined to ditch the current segment numbering
scheme and switch to one where the FullTransactionId of the first
entry in the segment is used for its name, so that admins can more
easily understand what the files under there correspond to.
--
Thomas Munro
https://enterprisedb.com