On Sat, Nov 29, 2014 at 11:46 PM, Jim Nasby jim.na...@bluetreble.com wrote:
What do you mean by never succeed? Is it skipping a large number of pages?
Might re-trying the locks within the same vacuum help, or are the user locks
too persistent?
You are confused. He's talking about the
Robert Haas wrote:
On Sat, Nov 29, 2014 at 11:46 PM, Jim Nasby jim.na...@bluetreble.com wrote:
What do you mean by never succeed? Is it skipping a large number of pages?
Might re-trying the locks within the same vacuum help, or are the user locks
too persistent?
You are confused. He's
On 12/02/2014 10:35 AM, Alvaro Herrera wrote:
If the table is large, the time window for this to happen is large also;
there might never be a time window large enough between two lock
acquisitions for one autovacuum run to complete in a table. This
starves the table from vacuuming completely,
On 2014-12-02 11:02:07 -0800, Josh Berkus wrote:
On 12/02/2014 10:35 AM, Alvaro Herrera wrote:
If the table is large, the time window for this to happen is large also;
there might never be a time window large enough between two lock
acquisitions for one autovacuum run to complete in a
On 12/02/2014 11:08 AM, Andres Freund wrote:
On 2014-12-02 11:02:07 -0800, Josh Berkus wrote:
On 12/02/2014 10:35 AM, Alvaro Herrera wrote:
If the table is large, the time window for this to happen is large also;
there might never be a time window large enough between two lock
acquisitions
On 2014-12-02 11:12:40 -0800, Josh Berkus wrote:
On 12/02/2014 11:08 AM, Andres Freund wrote:
On 2014-12-02 11:02:07 -0800, Josh Berkus wrote:
On 12/02/2014 10:35 AM, Alvaro Herrera wrote:
If the table is large, the time window for this to happen is large also;
there might never be a time
On Tue, Dec 2, 2014 at 11:12 AM, Josh Berkus j...@agliodbs.com wrote:
On 12/02/2014 11:08 AM, Andres Freund wrote:
On 2014-12-02 11:02:07 -0800, Josh Berkus wrote:
On 12/02/2014 10:35 AM, Alvaro Herrera wrote:
If the table is large, the time window for this to happen is large
also;
On 2014-12-02 11:23:31 -0800, Jeff Janes wrote:
I think it would be more promising to work on downgrading lock strengths so
that fewer things conflict, and it would be not much more work than what
you propose.
I think you *massively* underestimate the effort required to to lower
lock levels.
On Tue, Dec 2, 2014 at 11:41 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-12-02 11:23:31 -0800, Jeff Janes wrote:
I think it would be more promising to work on downgrading lock strengths
so
that fewer things conflict, and it would be not much more work than what
you propose.
On 2014-12-02 12:22:42 -0800, Jeff Janes wrote:
Or maybe I overestimate how hard it would be to make vacuum
restartable.
That's a massive project. Which is why I'm explicitly *not* suggesting
that. What I instead suggest is a separate threshhold after which vacuum
isn't going to abort
On 12/2/14, 2:22 PM, Jeff Janes wrote:
Or maybe I overestimate how hard it would be to make vacuum restartable. You
would have to save a massive amount of state (upto maintenance_work_mem tid
list, the block you left off on both the table and all of the indexes in that
table), and you would
Hi,
I've more than once seen that autovacuums on certain tables never
succeed because regular exclusive (or similar) lockers cause it to give
way/up before finishing. Usually if some part of the application uses
explicit exclusive locks.
In general I think it's quite imortant that autovacuum
On Nov 29, 2014 9:23 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
I've more than once seen that autovacuums on certain tables never
succeed because regular exclusive (or similar) lockers cause it to give
way/up before finishing. Usually if some part of the application uses
explicit
On 11/29/14, 2:22 AM, Andres Freund wrote:
Hi,
I've more than once seen that autovacuums on certain tables never
succeed because regular exclusive (or similar) lockers cause it to give
way/up before finishing. Usually if some part of the application uses
explicit exclusive locks.
In general I
14 matches
Mail list logo
