On Mon, Aug 22, 2022 at 02:36:36PM -0400, Robert Haas wrote:
> (Incidentally, there's also a bug in pg_waldump here: it's reporting
> the wrong LSN as the source of the error. 0/4FFF700 is not the record
> that's busted, as shown by the fact that it was successfully decoded
> and shown in the output. The relevant code in pg_waldump should be
> using EndRecPtr instead of ReadRecPtr to report the error. If it did,
> it would complain about 0/4FFFEA8, which is where the problem really
> is. This is of the same vintage as the bug fixed by
> d9fbb8862959912c5266364059c0abeda0c93bbf, though in that case the
> issue was reporting all errors using the start LSN of the first of
> several records read no matter where the error actually happened,
> whereas in this case the error is using the start LSN of the previous
> record instead of the current one.)
There was some previous discussion on this [0] [1].
[0] https://postgr.es/m/2B4510B2-3D70-4990-BFE3-0FE64041C08A%40amazon.com
[1] https://postgr.es/m/20220127.100738.1985658263632578184.horikyota.ntt%40gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com