Hi,
On 2022-11-09 18:35:12 -0800, Peter Geoghegan wrote:
> On Wed, Nov 9, 2022 at 6:10 PM Andres Freund <andres@anarazel.de> wrote:
> > And thinking about it, it'd be quite bad if the horizon worked that way. You can easily construct a workload where
everysingle xid would "skewer" some chain, never allowing the horizon to be raised.
>
> Your whole scenario is one involving a insert of a tuple by XID 10,
> which is then updated by XID 5 -- a lower XID. Obviously that's
> possible, but it's relatively rare. I have to imagine that the vast
> majority of updates affect tuples inserted by an XID before the XID of
> the updater.
> My use of the term "skewer" was limited to updates that look like
> that. So I don't know what you mean about never allowing the horizon
> to be raised.
You don't need it to happen all the time, it's enough when it happens
occasionally, since that'd "block" the whole range of xids between. So you
you'd just need occasional transactions to prevent the horizon from
increasing.
Anyway, I played a bit around with this. It's hard to hit, not because we
somehow won't choose such a horizon, but because we'll commonly prune the
earlier tuple version away due to xmax being old enough. It *is* possible to
hit, if the horizon increases between the two tuple version checks (e.g. if
there's another tuple inbetween that we check the visibility of).
I think there's another way it can happen in older cluster, but don't want to
spend the time to verify it.
Either way, we can't error out in this situation - there's nothing invalid
about it.
Greetings,
Andres Freund