agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Steve Singer <steve@ssinger.info>
Cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Jose Luis Tallon <jltallon@adv-solutions.net>
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Date: Thu, 28 Jan 2021 14:42:40 +0300
Message-ID: <55c6c1526b94d2caf54c33262fe00674@postgrespro.ru> (raw)
In-Reply-To: <20210127213658.GA736@alvherre.pgsql>
References: <20210127213658.GA736@alvherre.pgsql>
On 2021-01-28 00:36, Alvaro Herrera wrote:
> On 2021-Jan-28, Alexey Kondratov wrote:
>
>> I have read more about lock levels and ShareLock should prevent any
>> kind of
>> physical modification of indexes. We already hold ShareLock doing
>> find_all_inheritors(), which is higher than ShareUpdateExclusiveLock,
>> so
>> using ShareLock seems to be safe here, but I will look on it closer.
>
> You can look at lock.c where LockConflicts[] is; that would tell you
> that ShareLock indeed conflicts with ShareUpdateExclusiveLock ... but
> it
> does not conflict with itself! So it would be possible to have more
> than one process doing this thing at the same time, which surely makes
> no sense.
>
Thanks for the explanation and pointing me to the LockConflicts[]. This
is a good reference.
>
> I didn't look at the patch closely enough to understand why you're
> trying to do something like CLUSTER, VACUUM FULL or REINDEX without
> holding full AccessExclusiveLock on the relation. But do keep in mind
> that once you hold a lock on a relation, trying to grab a weaker lock
> afterwards is pretty pointless.
>
No, you are right, we are doing REINDEX with AccessExclusiveLock as it
was before. This part is a more specific one. It only applies to
partitioned indexes, which do not hold any data, so we do not reindex
them directly, only their leafs. However, if we are doing a TABLESPACE
change, we have to record it in their pg_class entry, so all future leaf
partitions were created in the proper tablespace.
That way, we open partitioned index relation only for a reference, i.e.
read-only, but modify pg_class entry under a proper lock
(RowExclusiveLock). That's why I thought that ShareLock will be enough.
IIUC, 'ALTER TABLE ... SET TABLESPACE' uses AccessExclusiveLock even for
relations with no storage, since AlterTableGetLockLevel() chooses it if
AT_SetTableSpace is met. This is very similar to our case, so probably
we should do the same?
Actually it is not completely clear for me why ShareUpdateExclusiveLock
is sufficient for newly added SetRelationTableSpace() as Michael wrote
in the comment.
Regards
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
view thread (154+ messages) latest in thread
Message-ID: <55c6c1526b94d2caf54c33262fe00674@postgrespro.ru>
Permalink: ../55c6c1526b94d2caf54c33262fe00674@postgrespro.ru/
Also on: postgresql.org/message-id/55c6c1526b94d2caf54c33262fe00674@postgrespro.ru
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.kondratov@postgrespro.ru, alvherre@alvh.no-ip.org, michael@paquier.xyz, pryzby@telsasoft.com, peter.eisentraut@enterprisedb.com, masahiko.sawada@2ndquadrant.com, steve@ssinger.info, robertmhaas@gmail.com, a.korotkov@postgrespro.ru, sawada.mshk@gmail.com, jltallon@adv-solutions.net
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
In-Reply-To: <55c6c1526b94d2caf54c33262fe00674@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox