| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Graham <mgraham(at)bloxx(dot)com> |
| Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Vacuum as "easily obtained" locks |
| Date: | 2011-08-03 15:52:02 |
| Message-ID: | 18238.1312386722@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Michael Graham <mgraham(at)bloxx(dot)com> writes:
> Ah! This looks like it is very much the issue. Since I've got around
> 150GB of data that should be truncatable and a select every ~2s.
> Just to confirm would postgres write:
> 2011-08-03 16:09:55 BST ERROR: canceling autovacuum task
> 2011-08-03 16:09:55 BST CONTEXT: automatic vacuum of table
> "traffic.public.logdata5queue"
> Under those circumstances?
Yup ...
If you do a manual VACUUM, it won't allow itself to get kicked off the
lock ... but as noted upthread, that will mean your other queries get
blocked till it's done. Not sure there's any simple fix for this that
doesn't involve some downtime.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2011-08-03 16:33:49 | Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages |
| Previous Message | Michael Graham | 2011-08-03 15:45:41 | Re: Vacuum as "easily obtained" locks |