Hello, Antonin. > I'm trying to review the patch, but not sure if I understand this problem, > please see my comment below.
Thanks a lot for your attention. It is strongly recommended to look at version N3 (1) because it is a much more elegant, easy, and reliable solution :) But the minRecoveryPoint-related issue affects it anyway. > Why doesn't minRecoveryPoint get updated to 20? IMO that should happen by > replaying the commit record. And if the standby happens to crash before the > commit record could be replayed, no query should see the deletion and thus no > hint bit should be set in the index. minRecoveryPoint is not affected by replaying the commit record in most cases. It is updated in a lazy way, something like this: minRecoveryPoint = max LSN of flushed page. Version 3 of a patch contains a code_optional.patch to move minRecoveryPoint more aggressively to get additional performance on standby (based on Peter’s answer in (2). So, “minRecoveryPoint will go here” is not because of “STANDBY INSERTS NEW ROW IN INDEX” it is just a random event. Thanks, Michail. [1]: https://www.postgresql.org/message-id/CANtu0ohHu1r1xQfTzEJuxeaOMYncG7xRxUQWdH%3DcMXZSf%2Bnzvg%40mail.gmail.com [2]: https://www.postgresql.org/message-id/CAH2-WzkSUcuFukhJdSxHFgtL6zEQgNhgOzNBiTbP_4u%3Dk6igAg%40mail.gmail.com (“Also, btw, do you know any reason to keep minRecoveryPoint at a low value?”)