> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>>> After:
>>> interval_start num_transactions sum_latency sum_latency_2 min_latency max_latency
>>> { failures | serialization_failures deadlock_failures } [ sum_lag sum_lag_2 min_lag max_lag [ skipped ] ] [ retried
retries]
>
>> I think that the explanatory paragraph is way too long now, particularly
>> since it explains --failures-detailed starting in the middle. Also, the
>> example output doesn't include the failures-detailed mode.
>
> I think the problem is not merely one of documentation, but one of
> bad design. Up to now it was possible to tell what was what from
> counting the number of columns in the output; but with this design,
> that is impossible. That should be fixed. The first thing you have
> got to do is drop the alternation { failures | serialization_failures
> deadlock_failures }. That doesn't make any sense in the first place:
> counting serialization and deadlock failures doesn't make it impossible
> for other errors to occur. It'd probably make the most sense to have
> three columns always, serialization, deadlock and total.
+1.
> Now maybe
> that change alone is sufficient, but I'm not convinced, because the
> multiple options at the end of the line mean we will never again be
> able to add any more columns without reintroducing ambiguity. I
> would be happier if the syntax diagram were such that columns could
> only be dropped from right to left.
Or those three columns always, sum_lag sum_lag_2, min_lag max_lag, skipped, retried retries?
Anyway now that current CF is closing, it will not be possible to
change those logging design soon. Or can we change the logging design
even after CF is closed?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
