On Fri, Feb 16, 2024 at 1:57 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> For me, the part that I feel most uneasy about is the decoding while the
> snapshot is still being built (and can flip to consistent snapshot
> between the relfilenode creation and sequence change, confusing the
> logic that decides which changes are transactional).
>
> It seems "a bit weird" that we either keep the "simple" logic that may
> end up with incorrect "non-transactional" result, but happens to then
> work fine because we immediately discard the change.
>
> But it still feels better than the alternative, which requires us to
> start decoding stuff (relfilenode creation) before building a proper
> snapshot is consistent, which we didn't do before - or at least not in
> this particular way. While I don't have a practical example where it
> would cause trouble now, I have a nagging feeling it might easily cause
> trouble in the future by making some new features harder to implement.
I don't understand the issues here well enough to comment. Is there a
good write-up someplace I can read to understand the design here?
Is the rule that changes are transactional if and only if the current
transaction has assigned a new relfilenode to the sequence?
Why does the logic get confused if the state of the snapshot changes?
My naive reaction is that it kinda sounds like you're relying on two
different mistakes cancelling each other out, and that might be a bad
idea, because maybe there's some situation where they don't. But I
don't understand the issue well enough to have an educated opinion at
this point.
--
Robert Haas
EDB: http://www.enterprisedb.com