Seems I underestimated the importance of forensic breadcrumbs.
On 6/9/2010 12:09 PM, Tom Lane wrote:
> I do like the idea of using a status bit rather than FrozenXid to mark a
> frozen tuple, because that eliminates the conflict between wanting to
> freeze aggressively for performance reasons and wanting to preserve Xids
> for forensic reasons. But it doesn't seem to do much for Josh's
> original problem.
Depends. Specifically on transaction profiles and how long the blocks
linger around before being written. If you can set the all visible bit
by the time, the page is written the first time, what bit including the
is-frozen one cannot be set at that time too?
Maybe some analysis on the typical behavior of such system is in order.
Especially the case Josh was mentioning seems to be a typical single
insert logging style application, with little else going on on that
particular database. I can't reveal specifics about that particular
case, but think of something like taking frequent sensor readings, that
need to be kept for years for forensics in case there is a product
recall some day.
And even if some cases still required another page write because those
frozen bits cannot be set on first write, this seems to be a win-win. We
would get rid of the FrozenXid completely and shift to a bit, so we can
effectively have a min_ freeze_age of zero while keeping the xid's forever.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin