Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Michael Banck
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 1552685574.9697.26.camel@credativ.de
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: REINDEX CONCURRENTLY 2.0
List 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.banck@credativ.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Next
From: Michael Meskes
Date:
Subject: Re: SQL statement PREPARE does not work in ECPG