Karsten Hilbert <Karsten.Hilbert@xxxxxxx> 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
