On 08/03/11 13:03, Mark Kirkwood wrote:
On 08/03/11 12:55, Mark Kirkwood wrote:
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done
On Mon, Mar 7, 2011 at 11:55 PM, Mark Kirkwood
wrote:
> stuff | 23957 | 2011-03-08 06:02:02.659159+13 | VACUUM ANALYZE;
>
For what it's worth VACUUM ANALYZE does have to take an additional
lock to update the statistics. It should rarely cause any problems but
it is a possibility.
When you d
On 08/03/11 12:55, Mark Kirkwood wrote:
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (fore
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (forever?). However if vacuum
eventually conti
On 23/02/11 03:27, Robert Haas wrote:
On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark wrote:
Actually it's not waiting for the LockBuffer LWLock. it's waiting
until your query unpins the buffer it wants. Vacuum tries to get an
exclusive lock on the buffer, if it gets it then it checks if anyone
is
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (forever?). However if vacuum
eventually continued when the query was canceled then it
On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark wrote:
> Actually it's not waiting for the LockBuffer LWLock. it's waiting
> until your query unpins the buffer it wants. Vacuum tries to get an
> exclusive lock on the buffer, if it gets it then it checks if anyone
> is using that buffer. If someone is
On Tue, Feb 22, 2011 at 7:14 AM, Mark Kirkwood
wrote:
> On 22/02/11 19:47, Heikki Linnakangas wrote:
>>
>> A long query on the same table can block vacuum. Vacuum needs to take a
>> so-called "cleanup lock" on each page, which means that it has to wait until
>> no other backend holds a pin on the
On 22/02/11 19:47, Heikki Linnakangas wrote:
A long query on the same table can block vacuum. Vacuum needs to take
a so-called "cleanup lock" on each page, which means that it has to
wait until no other backend holds a pin on the page. A long-running
query can keep a page pinned for a long ti
On 22.02.2011 05:43, Mark Kirkwood wrote:
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting | current_query
+--
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting
|
current_query
11 matches
Mail list logo
