Kouber Saparev <kouber@gmail.com> writes:
> На чт, 27.02.2020 г. в 17:52 Tom Lane <tgl@sss.pgh.pa.us> написа:
>> FWIW, I can't immediately think of a reason this would cause a problem,
>> at least not on 9.4 and up which use MVCC catalog scans. If you're
>> really still on 9.3 then it's notably more risky. In any case, I've
>> not had any caffeine yet today, so this doesn't count for much.
> Ah, 9.3 is not using MVCC for system catalogs?... Ouch. Then most probably
> it is really not a good idea. That said, I am not modifying table names,
> only index names... and I guess the internals, the planner etc. are not
> working with names, but with oids instead?
The issue is whether a SnapshotNow scan would find any row at all.
If it reaches the new row version before that's committed good, and
the old one after that's committed dead, you'll get some weird
"cache lookup failed" or similar failure --- just transiently, but
nonetheless a failure. Pre-9.4 versions were dependent on proper
locking to avoid that issue, and what you propose would bypass that.
regards, tom lane
