Re: storing an explicit nonce

From: Andres Freund <andres(at)anarazel(dot)de>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>
Subject: Re: storing an explicit nonce
Date: 2021-05-26 23:46:29
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2021-05-25 22:23:46 -0400, Stephen Frost wrote:
> Andres mentioned other possible cases where the LSN doesn’t change even
> though we change the page and, as he’s probably right, we would have to
> figure out a solution in those cases too (potentially including cases like
> crash recovery or replay on a replica where we can’t really just go around
> creating dummy WAL records to get new LSNs..).

Yea, I think there's quite a few of those. For one, we don't guarantee
that that the hole between pd_lower/upper is zeroes. It e.g. contains
old tuple data after deleted tuples are pruned away. But when logging an
FPI, we omit that range. Which means that after crash recovery the area
is zeroed out. There's several cases where padding can result in the

Just look at checkXLogConsistency(), heap_mask() et al for all the
differences that can occur and that need to be ignored for the recovery
consistency checking to work.

Particularly the hole issue seems trivial to exploit, because we know
the plaintext of the hole after crash recovery (0s).

I don't see how using the LSN alone is salvagable.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-05-27 00:11:24 Re: storing an explicit nonce
Previous Message Alvaro Herrera 2021-05-26 23:44:03 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?