> 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.eisentr...@2ndquadrant.com>: > >On 31/07/2018 23:10, Peter Eisentraut wrote: >> 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
