Re: Improve the concurency of vacuum full table and select statement on the same relation

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" <robertmhaas(at)gmail(dot)com> wrote:
>On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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