Re: [PATCH] Unremovable tuple monitoring

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Royce Ausburn <royce(dot)ml(at)inomial(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>
Subject: Re: [PATCH] Unremovable tuple monitoring
Date: 2011-11-16 01:26:11
Message-ID: CA+TgmoZdJ2dXk4xQwQ94hNZo_2HW8oHZTu-iMnoOm=wsiV6f1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2011 at 7:59 PM, Royce Ausburn <royce(dot)ml(at)inomial(dot)com> wrote:
>> Personally I think some log output, done better, would have been more useful for me at the time.  At the time I was trying to diagnose an ineffective vacuum and postgres' logs weren't giving me any hints about what was wrong.  I turned to the mailing list and got immediate help, but I felt that ideally postgres would be logging something to tell me that some 1 day old transactions were preventing auto vacuum from doing its job.  Something, anything that I could google.  Other novices in my situation probably wouldn't know to look in the pg_stats* tables, so in retrospect my patch isn't really achieving my original goal.
>>
>> Should we consider taking a logging approach instead?
>
> Dopey suggestion:
>
> Instead of logging around vacuum and auto_vacuum, perhaps log transactions that are open for longer than some (perhaps configurable) time?  The default might be pretty large, say 6 hours.  Are there common use cases for txs that run for longer than 6 hours?  Seeing a message such as:
>
> WARNING: Transaction <X> has been open more than Y.  This tx may be holding locks preventing other txs from operating and may prevent vacuum from cleaning up deleted rows.
>
> Would give a pretty clear indication of a problem :)

Well, you could that much just by periodically querying pg_stat_activity.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2011-11-16 01:49:17 Re: ISN was: Core Extensions relocation
Previous Message Joshua Berkus 2011-11-16 01:19:14 Re: pg_restore --no-post-data and --post-data-only