Dimitri Fontaine wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Well, it would still be useful, as it would shorten the delay. But yeah,
>> there's a delay in asynchronous replication anyway, so we decided to
>> keep it simple and just poll. It's not ideal and definitely needs to be
>> revisited for synchronous mode in the future. Same for walsenders.
>
> Stop me if I misunderstood the case at hand, but while waiting some more
> for having a sizeable batch to send makes a lot of sense to me, waiting
> on the receiver side when there's some work to do will only forbids a
> slow slave to keep up with the load, increasing lag artificially.
>
> I'm used to asynchronous replication where you're never allowed to rest
> if some batch is ready for you to process.
When the startup process wakes up after sleep to replay WAL, it does
replay all the WAL streamed that far. And if more WAL if streamed during
the replay, it's replayed too before the next sleep. But when it does
reach the end of already-streamed WAL, it sleeps for 100ms, and doesn't
wake up earlier if a WAL record arrives during the sleep.
So, it does increase the lag artificially, but it will keep up with the
volume just fine.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com