The lock upgrade for vacuum full table tends to cause deadlock with other lock 
upgrade transaction which is from AccessShareLock to lockmode > 
AccessShareLock.  Tom Lane's concern is that it will cause vacuum full failed 
after do a lot of work.
But If we can always let other transaction failed to break deadlock instead of 
vacuum full table,  how about this lock upgrade solution?
For example: we can enlarge the 'DeadlockTimeout' for vacuum full table 
transaction to avoid deadlock check.

Jinyu Zhang

At 2015-10-16 23:04:51, "Robert Haas" <> wrote:
>On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby <> wrote:
>> It's just how the authors of pg_repack decided to handle it. It seems pretty
>> reasonable, since you probably don't want an errant DDL statement to cause
>> the rollback of hours or days of pg_repack work.
>> Ultimately, I don't think you'll find many people interested in working on
>> this, because the whole goal is to never need VACUUM FULL or pg_repack. If
>> you're clustering just for the sake of clustering, that has it's own set of
>> difficulties that should be addressed.
>I think the topic of online table reorganization is a pretty important
>one, actually.  That is a need that we have had for a long time,
>creates serious operational problems for users, and it's also a need
>that is not going away.  I think the chances of eliminating that need
>completely, even if we rearchitected or heap storage, are nil.
>I think the bigger issue is that it's a very hard problem to solve.
>pg_repack is one approach, but I've heard more than one person say
>that, as C-3PO said about the asteroid, it may not be entirely stable.
>Robert Haas
>The Enterprise PostgreSQL Company

Reply via email to