Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> On Thu, Jan 12, 2006 at 07:46:18PM -0500, Tom Lane wrote:
>> The comment's "have to" is an overstatement. The transaction would be
>> treated as crashed anyway, it's just that this is a convenient place to
>> make pg_clog a bit cleaner. I'm not real sure why we bother, actually.
> Because that's what makes PostgreSQL such a reliable
> product. You follow your intuition and taste and bother
> doing cleanup even if you cannot immediately tell whether
> it's *really* needed.
Well, this is not a correctness issue. If it were, XactLockTableWait
would be quite the wrong place for it, because there's no guarantee
anyone will ever do XactLockTableWait for any particular transaction ID.
In fact, now that I look at it, I'm pretty well convinced this is dead
code: we only ever wait for XIDs that are known to have been alive in
the recent past, ie, within the lifespan of the current backend. So the
case should never occur ... unless possibly in the microseconds before
we receive SIGQUIT from the postmaster because the other guy crashed,
and in that situation trying to issue a write on pg_clog is probably
not the brightest action to be taking anyway. This could easily
represent a net minus for reliability, not a plus, if it increases the
risk of pg_clog getting corrupted during a crash sequence.
regards, tom lane