Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > 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.
Thanks for the clear picture. It then works the same as PGQ based consumers, including londiste. I'm now happy ☻ > So, it does increase the lag artificially, but it will keep up with the > volume just fine. Great. No further complain from me there. I guess it now entirely depends on how easy it is to wake up before the end of the 100ms: it might be that it's easier to code the signaling than to add a GUC for the value? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
