Matthias van de Meent

> But still I do not understand why do we need to split data and metadata in LwLSN cache. Because the Startup process won't ever have to wait for other...

> But if we prohibit eviction of entries from LwLSN cache entries with LSN>replayed_lsn, then there will be no such problem, right? We don't store entries for Metadata, instead we...

I think redo locking P1 -> P2 and backends locking P2 -> P1 will always be sensitive to deadlocks, regardless of this change - we don't have lightweight deadlock detection,...

I don't think this is valid, as this could cause issues when changes to some pages now become visible before others, where previously they would become visible at exactly the...

The issue is that it is possible for a backend to see modifications on page X that depend on modifications in page Y, but won't see those changes in page...

> It seems to me that the only possible solution is to get buffer and hold lock even if we are not going to reconstruct the page. No, I think...

I think you misunderstand: Right now, we always update LwLsn, and then, optionally, read the page if the page was in shared buffers or LFC. Instead, the "and then, optionally,...

> > Right now, we always update LwLsn, and then, optionally, read the page if the page was in shared buffers or LFC. > > It is not true: >...

> it is not correct to call XLogWaitForReplayOf(reqlsns->request_lsn) because request_lsn=replay_lsn. But that's correct, as replay_lsn is the LSN of the last completely replayed record (done with), not the one we're...

> But still I do not see any sense in XLogWaitForReplayOf(reqlsns->request_lsn) We have to wait for the "replay lock" on the LwLSN of the page to expire. The LwLSN, which...