Re: 64 bit transaction id

On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
> >On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
> >> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> >> > And "without causing significant issues elsewhere" unfortunately
> >> > includes continuing to allow pg_upgrade to work.
> >
> >> Yeah. I suppose we could have a different AM implementing this, but
> >> maybe that's not possible ...
> >
> >Entirely possible. But the amount of code duplication / unnecessary
> >branching and the user confusion from two very similar AMs, would have
> >to be weighed against the benefits.
> >
>
> Agreed. I think code complexity is part of the trade-off. IMO it's fine
> to hack existing heap AM initially, and only explore the separate AM if
> that turns out to be promising.

I thought a bit about how to make a minimally-diffferent-from-heap
non-freezing table AM using 64 bit xids, as a thought experiment when
trying to understand or explain to others what zheap is about.
Committed transactions are easy (you don't have to freeze fxid
references from the ancient past because they don't wrap around so
they always look old), but how do you deal with *aborted* transactions
when truncating the CLOG (given that our current rule is "if it's
before the CLOG begins, it must be committed")? I see three
possibilities: (1) don't truncate the CLOG anymore (use 64 bit
addressing and let it leak disk forever, like we did before commit
2589735d and later work), (2) freeze aborted transactions only, using
a wraparound vacuum (and now you have failed, if the goal was to avoid
having to scan all tuples periodically to freeze stuff, though
admittedly it will require less IO to freeze only the aborted
transactions), (3) go and remove aborted fxid references eagerly, when
you roll back (this could be done using the undo technology that we
have been developing to support zheap). Another way to explain (3) is
that this hypothetical table AM, let's call it "yheap", takes the
minimum parts of the zheap technology stack required to get rid of
vacuum-for-wraparound, without doing in-place updates or any of that
hard stuff. To make this really work you'd also have to deal with
multixacts, which also require freezing. If that all sounds too
complicated, you're back to (2) which seems a bit weak to me. Or
perhaps I'm missing something?