On Thu, Jul 25, 2019 at 02:05:05PM -0400, Bruce Momjian wrote:
> The second approach is to say they will collide and that we need to mix
> a constant into the IV for tables/indexes and a different one for WAL.
> In a way I would like to mix the pg_controldata Database system
> Identifier into there too, but I am unclear on the value and complexity
> involved.
>
> A third approach would be to say that we will have duplicate LSNs
> between a table and its index? Maybe we need three constants, one for
> heap, one for indexes, and one for WAL.
>
> A fourth approach would be to say we will have duplicate LSNs on
> different heap files, or index files. We would then modify pg_upgrade to
> preserve relfilenode and use that. (I don't think pg_class.oid is
> visible during recovery, and it certainly isn't visible in offline
> mode.)
>
> However, we need to be clear that adding relfilenode is only helping to
> avoid tables/indexes with the same LSN pages. It doesn't address the
> 68GB limit since our tables can be larger than that.
>
> A fifth approach would be to decide that 68GB is the limit for a single
> key (not single key/IV combo). If that is the case we need a different
> key for each 68GB of a file, and because we break files into 1GB chunks,
> we would just use a different key for each chunk, and I guess store the
> keys in the file system, encrypted with the master key.
>
> My big point is that we need to decide where the IV collisions will
> happen, and what our encryption limit per key (not per key/IV
> combination) is.
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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
