Hello, Peter.
> I wonder if it would help to not actually use the LP_DEAD bit for
> this. Instead, you could use the currently-unused-in-indexes
> LP_REDIRECT bit.
Hm… Sound very promising - an additional bit is a lot in this situation.
> Whether or not "recently dead" means "dead to my
> particular MVCC snapshot" can be determined using some kind of
> in-memory state that won't survive a crash (or a per-index-page
> epoch?).
Do you have any additional information about this idea? (maybe some thread). What kind of “in-memory state that won't survive a crash” and how to deal with flushed bits after the crash?
> "Not known to be dead in any sense" (0), "Unambiguously dead to all"
> (what we now simply call LP_DEAD), "recently dead on standby"
> (currently-spare bit is set), and "recently dead on primary" (both
> 'lp_flags' bits set).
Hm. What is about this way:
10 - dead to all on standby (LP_REDIRECT)
11 - dead to all on primary (LP_DEAD)
01 - future “recently DEAD” on primary (LP_NORMAL)
In such a case standby could just always ignore all LP_DEAD bits from primary (standby will lose its own hint after FPI - but it is not a big deal). So, we don’t need any conflict resolution (and any additional WAL records). Also, hot_standby_feedback-related stuff is not required anymore. All we need to do (without details of course) - is correctly check if it is safe to set LP_REDIRECT on standby according to `minRecoveryPoint` (to avoid consistency issues during crash recovery). Or, probably, introduce some kind of `indexHintMinRecoveryPoint`.
Also, looks like both GIST and HASH indexes also do not use LP_REDIRECT.
So, it will remove more than 80% of the current patch complexity!
Also, btw, do you know any reason to keep minRecoveryPoint at a low value? Because it blocks standby for settings hints bits in *heap* already. And, probably, will block standby to set *index* hint bits aggressively.
Thanks a lot,
Michail.
