Heikki Linnakangas <heikki@enterprisedb.com> 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
