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?
