marcin mank <marcin.m...@gmail.com> writes:
> Could a tuple wih the bit set be considered frozen already? Would we
> actually ever need to rewrite the xmin, even for anti-wraparound
> reasons?
That's exactly what Simon is suggesting: if we had a tuple status flag
with the semantics of "this xmin is known visible to all current and
future transactions", we could consider setting that bit to be the moral
equivalent of freezing the tuple. The tuple visibility tests would
never actually consult clog for such an xmin and thus we'd never have to
replace it with FrozenXid.
But this doesn't in itself save us any work: we'd still need to treat
setting that bit as a WAL-logged operation, and we'd still need to have
VACUUM track the oldest not-thus-hinted xmins. What it does do is
eliminate the conflict between wanting to freeze tuples aggressively for
various performance reasons and wanting to preserve original xmin values
for forensic reasons.
I wonder how this might play into Heikki's ideas about making the
visibility map trustworthy. If we WAL-logged the operation of "set all
the per-tuple VISIBLE-TO-ALL bits on this page, as well as the page's
bit in the visibility map", then that end of things would be
trustworthy. And all the operations that have to unset the map bit
are already WAL-logged.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
