> 29 окт. 2015 г., в 14:03, Michael Paquier <michael.paqu...@gmail.com> > написал(а): > > On Thu, Oct 29, 2015 at 11:33 AM, Vladimir Borodin wrote: >> 29 окт. 2015 г., в 13:12, Michael Paquier написал(а): >>> In the case of repeatable read the standby will wait before applying >>> the VACUUM WAL record cleaning up a relation page. Hence you won't get >>> conflicts in this case. >> >> Standby will receive but will not apply? Or master will not vacuum needed by >> standby pages? It seems that the second one is happening because replication >> lag on standby does not increase while issuing such repeatable read >> transaction. > > Standby will receive the record but not replay it until the > transaction doing REPEATABLE READ transactions that needs those rows > commits on the standby. The WAL flush position on the standby > continues to move on.
By replication lag on standby I mean exactly replay_location, not flush_location. > This depends of course on > max_standby_streaming_delay which may decide or not to force the > transaction to cancel if it takes too long. Someone feel free to > correct me if I am missing something here. Well, the initial problem is that in read commited mode heavy SELECT-statement hits max_standby_streaming_delay but in repeatable read mode doesn’t. My question is if it is expected behavior? If yes, why is it so? Thanks for your response! > -- > Michael -- Да пребудет с вами сила… https://simply.name/ru
