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 regards At 2015-10-16 23:04:51, "Robert Haas" <robertmh...@gmail.com> wrote: >On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby <jim.na...@bluetreble.com> 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 >EnterpriseDB: http://www.enterprisedb.com >The Enterprise PostgreSQL Company
