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
