Commit a00d468e authored by Tom Lane's avatar Tom Lane

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.
parent 18f158ef
...@@ -1784,14 +1784,6 @@ index_update_stats(Relation rel, ...@@ -1784,14 +1784,6 @@ index_update_stats(Relation rel,
* trying to change the pg_class row to the same thing, so it doesn't * trying to change the pg_class row to the same thing, so it doesn't
* matter which goes first). * 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 * It is safe to use a non-transactional update even though our
* transaction could still fail before committing. Setting relhasindex * transaction could still fail before committing. Setting relhasindex
* true is safe even if there are no indexes (VACUUM will eventually fix * true is safe even if there are no indexes (VACUUM will eventually fix
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment