Re: REINDEX CONCURRENTLY 2.0

From: Michael Banck <michael(dot)banck(at)credativ(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Date: 2019-03-15 21:32:54
Message-ID: 1552685574.9697.26.camel@credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Am Mittwoch, den 13.03.2019, 23:10 +0100 schrieb Peter Eisentraut:
> Here is an updated patch.

I had a quick look at some of the comments and noticed some possible
nitpicky-level problems:

> +/*
> + * index_concurrently_set_dead
> + *
> + * Perform the last invalidation stage of DROP INDEX CONCURRENTLY or REINDEX
> + * CONCURRENTLY before actually dropping the index. After calling this
> + * function the index is seen by all the backends as dead. Low-level locks
> + * taken here are kept until the end of the transaction doing calling this
> + * function.
> + */

"the transaction doing calling this function." sounds wrong to me.

> + * Extract the list of indexes that are going to be rebuilt based on the
> + * list of relation Oids given by caller. For each element in given list,
> + * if the relkind of given relation Oid is a table, all its valid indexes
> + * will be rebuilt, including its associated toast table indexes. If
> + * relkind is an index, this index itself will be rebuilt. The locks taken
> + * on parent relations and involved indexes are kept until this
> + * transaction is committed to protect against schema changes that might
> + * occur until the session lock is taken on each relation, session lock
> + * used to similarly protect from any schema change that could happen
> + * within the multiple transactions that are used during this process.
> + */

I think the last sentence in the above should be split up into several
sentences, maybe at "session lock used..."? Or maybe it should just say
"a session lock is used" instead?

> + else
> + {
> + /*
> + * Save the list of relation OIDs in private
> + * context
> + */

Missing full stop at end of comment.

> + /* Definetely no indexes, so leave */

s/Definetely/Definitely/.

Michael

--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael(dot)banck(at)credativ(dot)de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2019-03-15 21:34:47 Re: SQL statement PREPARE does not work in ECPG
Previous Message Tom Lane 2019-03-15 21:10:23 Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3