From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
Cc: | General postgres mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_stat_activity xact_start and autovacuum |
Date: | 2008-02-11 14:14:01 |
Message-ID: | 20080211141401.GA7050@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dawid Kuroczko escribió:
> > Dawid Kuroczko escribió:
> > > I'm using 8.3.0 and I see that autovacuum processes in
> > > pg_stat_activity have xact_start.
> > >
> > > As far as I know, since at least 8.2.x the VACUUM does not start a new
> > > transaction.
> I am referrring to the E.8.3.5 Release 8.2 Release Notes:
>
> * Allow VACUUM to expire rows without being affected by other
> concurrent VACUUM operations (Hannu Krossing, Alvaro, Tom)
Oh, I see. Well, it is certainly running in a transaction, even though
that transaction does not prevent other vacuums from removing old rows.
> Right now I am using:
> SELECT extract('epoch' from min(xact_start)) AS oldest_xact_age
> FROM pg_stat_activity
> WHERE current_query NOT LIKE 'autovacuum:%';
>
> ...which works fine but somehow I feel that if xact_age would be NULL, it would
> ring more true. Since VACUUM does not prevent VACUUMING it can take
> days to complete and still I wouldn't need to worry. ;-)
Actually it's not just autovacuum; it's any lazy vacuum. It's hard to
tell those processes apart in pg_stat_activity. Perhaps we could have
added a column in pg_stat_activity indicating processes that don't hold
old tuples, but I feel that would have been a little too much.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-02-11 14:25:38 | Re: end of life for pg versions... |
Previous Message | Dawid Kuroczko | 2008-02-11 13:56:52 | Re: pg_stat_activity xact_start and autovacuum |