Re: Improve behavior of concurrent ANALYZE/VACUUM

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, "horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Improve behavior of concurrent ANALYZE/VACUUM
Date: 2018-08-22 05:36:37
Message-ID: 20180822053637.GC4333@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 22, 2018 at 02:17:44AM +0000, Bossart, Nathan wrote:
> I think this is doable by locking the table in SHARE mode. That won't
> conflict with the AccessShareLock that expand_vacuum_rel() obtains,
> but it will conflict with the ShareUpdateExclusiveLock or
> AccessExclusiveLock that vacuum_rel() takes.

Good point. Still is that really worth adding? This implies a test
which has at least two roles, one switching the ownership to the other
and do so back-and-forth. At least that should be on a different
isolation spec file to not complicate the first one.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-08-22 05:45:50 plan_cache_mode and postgresql.conf.sample
Previous Message Yamaji, Ryo 2018-08-22 04:54:18 RE: [HACKERS] Cached plans and statement generalization