| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | andy <andy(at)squeakycode(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [ADMIN] Vacuum error on database postgres |
| Date: | 2006-09-14 22:25:42 |
| Message-ID: | 16508.1158272742@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> How would creating a new lock type avoid deadlocks when an ANALYZE is
> accumulating the locks in random order?
In itself it wouldn't. Josh Drake sketched the idea in more detail
later: if there is a lock type used *only* for ANALYZE, then you can do
ConditionalLockAcquire on it, and if you fail, skip the table on the
assumption that someone else is already doing what you came to do.
The whole thing seems a bit too cute/complicated though; it'd open
various corner cases such as: ANALYZE, run complex query, query takes a
week because it's using out-of-date stats because previous ANALYZE-r
hadn't committed yet. I'd rather ANALYZE always analyzed than sometimes
fell through without doing anything.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2006-09-14 23:40:17 | Re: [ADMIN] Vacuum error on database postgres |
| Previous Message | Jeff Davis | 2006-09-14 21:57:25 | Re: [ADMIN] Vacuum error on database postgres |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-09-14 22:47:27 | Re: Release notes |
| Previous Message | Bruce Momjian | 2006-09-14 22:25:36 | Re: Release notes |