postgres.git / summary / log / commit / refs

commit    d1f8e7a01501c71db3ee0bcd19aab79b1ddc662e
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Tue Oct 28 22:36:02 2014 +0000
First released in: 9.5.0, 9.4.0

    Remove obsolete commentary.
    
    Since we got rid of non-MVCC catalog scans, the fourth reason given for
    using a non-transactional update in index_update_stats() is obsolete.
    The other three are still good, so we're not going to change the code,
    but fix the comment.


 src/backend/catalog/index.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index a5a204eb40b..f691dd30c19 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -1783,14 +1783,6 @@ index_update_stats(Relation rel,
 	 * trying to change the pg_class row to the same thing, so it doesn't
 	 * matter which goes first).
 	 *
-	 * 4. Even with just a single CREATE INDEX, there's a risk factor because
-	 * someone else might be trying to open the rel while we commit, and this
-	 * creates a race condition as to whether he will see both or neither of
-	 * the pg_class row versions as valid.  Again, a non-transactional update
-	 * avoids the risk.  It is indeterminate which state of the row the other
-	 * process will see, but it doesn't matter (if he's only taking
-	 * AccessShareLock, then it's not critical that he see relhasindex true).
-	 *
 	 * It is safe to use a non-transactional update even though our
 	 * transaction could still fail before committing.  Setting relhasindex
 	 * true is safe even if there are no indexes (VACUUM will eventually fix


[parent: 3345ba4d0d28]