So let's discuss the next step in this series: what to do about REINDEX CONCURRENTLY.
I started with Dmitry's patch (an updated version of which I already posted in [1]). However, Dmitry missed (and I hadn't noticed) that some of the per-index loops are starting transactions also, and that we need to set the flag in those. And what's more, in a couple of the function-scope transactions we do set the flag pointlessly: the transactions there do not acquire a snapshot, so there's no reason to set the flag at all, because WaitForOlderSnapshots ignores sessions whose Xmin is 0. There are also transactions that wait first, without setting a snapshot, and then do some catalog manipulations. I think it's prett much useless to set the flag for those, because they're going to be very short anyway. (There's also one case of this in CREATE INDEX CONCURRENTLY.) But there's a more interesting point also. In Dmitry's patch, we determine safety for *all* indexes being processed as a set, and then apply the flag only if they're all deemed safe. But we can optimize this, and set the flag for each index' transaction individually, and only skip it for those specific indexes that are unsafe. So I propose to change the data structure used in ReindexRelationConcurrently from the current list of OIDs to a list of (oid,boolean) pairs, to be able to track setting the flag individually. There's one more useful observation: in the function-scope transactions (outside the per-index loops), we don't touch the contents of any indexes; we just wait or do some catalog manipulation. So we can set the flag *regardless of the safety of any indexes*. We only need to care about the safety of the indexes in the phases where we build the indexes and when we validate them. [1] https://postgr.es/m/20201118175804.GA23027@alvherre.pgsql
