Re: stats for failed transactions (was Re: [GENERAL] VACUUM Question) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: stats for failed transactions (was Re: [GENERAL] VACUUM Question)
Date
Msg-id 20060127155338.GD18334@surnet.cl
Whole thread Raw
In response to stats for failed transactions (was Re: [GENERAL] VACUUM Question)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stats for failed transactions (was Re: [GENERAL] VACUUM Question)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: stats for failed transactions (was Re: [GENERAL] VACUUM  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Tom Lane wrote:

> I think this is the fault of the stats system design.  AFAICT from a
> quick look at the code, inserted/updated/deleted tuples are reported
> to the collector in the same way regardless of whether the sending
> transaction committed or rolled back.  I think this is unquestionably
> a bug, at least for autovacuum's purposes --- though it might be OK
> for the original intent of the stats system, which was simply to track
> activity levels.
> 
> Any thoughts about how it ought to work?

I don't remember exactly how it works -- I think the activity (insert,
update, delete) counters are kept separately from commit/rollback
status, right?  Maybe we should keep three separate counters: "current
transaction counters" and "counters for transactions that were
aborted/committed".  We only send the latter counts, and the former are
added to them when the transaction ends.

-- 
Alvaro Herrera                        http://www.advogato.org/person/alvherre
"Aprende a avergonzarte más ante ti que ante los demás" (Demócrito)


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Adding a --quiet option to initdb
Next
From: Tom Lane
Date:
Subject: Re: Adding a --quiet option to initdb