From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, 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-15 09:40:55 |
Message-ID: | 20060915094055.GD1608@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On Thu, Sep 14, 2006 at 06:25:42PM -0400, Tom Lane wrote:
> 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.
Wouldn't it be useful for ANALYZE to do a conditional lock anyway and
skip if it can't acquire. Especially for the analyse-from-autovacuum
case, perhaps an ANALYSE NOLOCK or whatever.
For stuff run from autovacuum, would it be reasonable for the
automatically run version to just abort if it sees someone doing the
same thing?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-09-15 10:33:00 | Re: [ADMIN] Vacuum error on database postgres |
Previous Message | Dilipkumar | 2006-09-15 07:55:32 | Re: install postgres8.1 on debian |
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar | 2006-09-15 10:07:05 | Re: [HACKERS] lower() not working correctly...? |
Previous Message | Martijn van Oosterhout | 2006-09-15 09:32:21 | Re: New version of money type |