Skip site navigation (1) Skip section navigation (2)

stats for failed transactions (was Re: [GENERAL] VACUUM Question)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: "Michael Fuhr" <mike(at)fuhr(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: stats for failed transactions (was Re: [GENERAL] VACUUM Question)
Date: 2006-01-27 14:26:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
>> Also, somebody made a real good point about rolled-back insertions.
>> Even if the only command you ever apply to the table is INSERT, you
>> could still have dead rows in the table if some of those transactions
>> occasionally roll back.

> hmm... That's true.  I don't think autovacuum doesn't anything to account
> for the concept of rolledback inserts.

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?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Mitchell SkinnerDate: 2006-01-27 15:00:21
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen
Previous:From: Tom LaneDate: 2006-01-27 14:12:11
Subject: Re: Proposal: new pg_dump options --copy-delimiter and --copy-null

pgsql-general by date

Next:From: Alexander PresberDate: 2006-01-27 14:40:56
Subject: Re: TSearch2 / German compound words / UTF-8
Previous:From: Matthew HendersonDate: 2006-01-27 14:21:31
Subject: Re: Accessing an old database from a new OS installation.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group