| From: | Royce Ausburn <royce(dot)ml(at)inomial(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 00:59:20 |
| Message-ID: | A6FD24AB-AFD2-4C7F-A1E6-EE8D0E1A5128@inomial.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> 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 :)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Berkus | 2011-11-16 01:09:30 | Re: ISN was: Core Extensions relocation |
| Previous Message | Peter Geoghegan | 2011-11-16 00:46:01 | Re: ISN was: Core Extensions relocation |