Re: Multixid hindsight design

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> So the lesson here is that having a permanent pg_multixact is not nice,
> and we should get rid of it. Here's how to do that:

That would be cool, but ...

> Looking at the tuple header, the CID and CTID fields are only needed,
> when either xmin or xmax is running. Almost: in a HOT-updated tuple,
> CTID is required even after xmax has committed, but since it's a HOT
> update, the new tuple is always on the same page so you only need the
> offsetnumber part.

I think this is totally wrong. HOT update or not, you need the forward
link represented by ctid not just until xmin/xmax commit, but until
they're in the past according to all active snapshots. That's so that
other transactions can chain forward to the "current" version of a tuple
which they found according to their snapshots.

It might be you can salvage the idea anyway, since it's still true that
the forward links wouldn't be needed after a crash and restart. But the
argument as stated is wrong.

(There's also the question of forensic requirements, although I'm aware
that it's barely worth bringing that up since nobody else here seems to
put much weight on that.)

regards, tom lane