Re[2]: Alter index rename concurrently to - Mailing list pgsql-hackers
| From | Andrey Klychkov |
|---|---|
| Subject | Re[2]: Alter index rename concurrently to |
| Date | |
| Msg-id | 1538567488.953452852@f403.i.mail.ru Whole thread Raw |
| In response to | Re: Alter index rename concurrently to (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Responses |
Re: Alter index rename concurrently to
(Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
|
| List | pgsql-hackers |
> Based on these assertions, here is my proposed patch. It lowers the
> lock level for index renaming to ShareUpdateExclusiveLock.
Hi, Peter
I made small review for your patch:
Server source code got from https://github.com/postgres/postgres.git
1. Patch was applied without any errors except a part related to documentation:
error: patch failed: doc/src/sgml/ref/alter_index.sgml:50
error: doc/src/sgml/ref/alter_index.sgml: patch does not apply
2. The code has been compiled successfully, configured by:
# ./configure CFLAGS="-O0" --enable-debug --enable-cassert --enable-depend --without-zlib
3. 'make' / 'make install' successfully made and complete.
4. The compiled instance has been started without any errors.
5. I realized several tests by the pgbench (with -c 4 -j 4 -T 360) that modified data into columns, indexed by pk and common btree.
In the same time there was a running script that was making renaming indexes multiple times in transactions with pg_sleep(1).
After several tests no errors were found.
6. pg_upgrade from 10 to 12 (patched) has been done without any errors / warnings
7. Code style:
+RenameRelationInternal(Oid myrelid, const char *newrelname, bool is_internal, bool is_index)
This line is longer than 80 chars.
Thank you
Вторник, 14 августа 2018, 9:33 +03:00 от Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
> On 27/07/2018 16:16, Robert Haas wrote:
>> With respect to this particular patch, I don't know whether there are
>> any hazards of the second type. What I'd check, if it were me, is
>> what structures in the index's relcache entry are going to get rebuilt
>> when the index name changes. If any of those look like things that
>> something that somebody could hold a pointer to during the course of
>> query execution, or more generally be relying on not to change during
>> the course of query execution, then you've got a problem.
>
> I have investigated this, and I think it's safe. Relcache reloads for
> open indexes are already handled specially in RelationReloadIndexInfo().
> The only pointers that get replaced there are rd_amcache and
> rd_options. I have checked where those are used, and it looks like they
> are not used across possible relcache reloads. The code structure in
> those two cases make this pretty unlikely even in the future. Also,
> violations would probably be caught by CLOBBER_CACHE_ALWAYS.
Based on these assertions, here is my proposed patch. It lowers the
lock level for index renaming to ShareUpdateExclusiveLock.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Regards,
Andrey Klychkov
pgsql-hackers by date: