On 05/12/2015 01:51 AM, Tom Lane wrote:
Heikki Linnakangas <hlinn...@iki.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.
Ah yes, I stated that wrong. What I meant was that they are not needed
after xmin and xmax are older than global xmin.
(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.)
I do care about that. In this scheme, you would always have the
updater/deleter XMAX on the tuple itself, which IMO is more useful for
forensic purposes than a multixid. You lose the CID and CTID in the
tuple (for tuples that are updated and locked at the same time), but if
you keep the TED around longer, you have all the information still
there. On the whole, I don't think this is much worse than the current
situation.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
