On Mon, Nov 11, 2024 at 6:17 AM Tomas Vondra <to...@vondra.me> wrote: > > If this analysis is correct, I think it's rather suspicious we don't > reset the candidate fields on restart. Can those "old" values ever be > valid? But I haven't tried resetting them.
I had the same question. IIRC resetting them also fixes the problem[1]. However, I got a comment from Alvaro[2]: Hmm, interesting -- I was studying some other bug recently involving the xmin of a slot that had been invalidated and I remember wondering if these "candidate" fields were being properly ignored when the slot is marked not in use; but I didn't check. Are you sure that resetting them when the slot is released is the appropriate thing to do? I mean, shouldn't they be kept set while the slot is in use, and only reset if we destroy it? Which made me re-investigate the issue and thought that it doesn't necessarily need to clear these candidate values in memory on releasing a slot as long as we're carefully updating restart_lsn. Which seems a bit efficient for example when restarting from a very old point. Of course, even if we reset them on releasing a slot, it would perfectly work since it's the same as restarting logical decoding with a server restart. I think LogicalIncreaseRestartDecodingForSlot() should be fixed as it seems not to be working expectedly, but I could not have proof that we should either keep or reset them on releasing a slot. Regards, [1] https://www.postgresql.org/message-id/CAD21AoBG2OSDOFTtpPtQ7fx5Vt8p3dS5hPAv28CBSC6z2kHx-g%40mail.gmail.com [2] https://www.postgresql.org/message-id/20230206152209.yglmntznhcmaueyn%40alvherre.pgsql -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
