On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra <tomas.von...@2ndquadrant.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?
