Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane kirjoitti: >> I'm also concerned about loss of debug traceability if these fields >> disappear entirely from disk --- it's been handy more than once to be >> able to tell where in a complex transaction something happened.
> Sure. We'll just have to try to compensate that with debug messages > etc., whatever scheme we choose. I think you completely misunderstand the context in which I'm concerned about that --- handwaving about "better debug messages" doesn't assuage the concern. In fact, since I wrote that message I've had another example of what stored cmin is good for: a few minutes ago, in connection with Marc Evan's issue here, http://archives.postgresql.org/pgsql-general/2006-09/msg00741.php we were able to eliminate a theory about an FK trigger having modified a row after its insertion by observing that the stored row still had cmin = 0. I've made use of cmin data in many prior cases to help identify what's what: in lots of real applications, the cmin value tells you exactly which kind of transaction inserted or modified the row, because different transactions have different numbers of steps. If cmin vanishes into transient storage then after-the-fact forensic analysis will be severely handicapped. No amount of "debug messages" will make up for data that's not there anymore when you realize you need it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
