Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica

Drive-by comment:

On Sat, Apr 23, 2022 at 11:02:04AM +0500, Andrey Borodin wrote:
> I've removed amcheck from the test and replaced it with a simple IndexOnlyScan. I'm not proposing to commit this test anyway, so I left it in amcheck.
> The test reliably fails in 30s or earlier.
>
> 2022-04-23 10:51:06.872 +05 [36192] 004_cic_standby.pl LOG: statement: select i from tbl where i = 236116;
> 2022-04-23 10:51:06.890 +05 [36192] 004_cic_standby.pl ERROR: could not open relation with OID 16671
> 2022-04-23 10:51:06.890 +05 [36192] 004_cic_standby.pl STATEMENT: select i from tbl where i = 236116;
>
> Adding AEL's seem to solve the problem.

If this thread proceeds with the current LogAccessExclusiveLock() design, I
think it must include a way to disable the new behavior. That requirement
would apply to any design that delays standby WAL apply in a way that
hot_standby_feedback can't mitigate. We have the vacuum_truncate reloption
because AEL is disruptive to standby freshness. Adding a new kind of
unavoidable AEL would be similarly-painful.

It would nicer to fix this such that, with hot_standby_feedback, the fix
delays CIC on the primary instead of delaying apply on the standby. If that's
too hard, AEL plus option-to-disable sounds fine.