Prev: SELECT constant; takes 15x longer on 9.0?
Next: recovery.conf.sample
From: Dimitri Fontaine on 6 Apr 2010 06:11
Heikki Linnakangas <heikki.linnakangas(a)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.

Regards,
--
dim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dimitri Fontaine on 6 Apr 2010 07:20
Heikki Linnakangas <heikki.linnakangas(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dimitri Fontaine on 6 Apr 2010 11:19
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
> Ok, here's a patch to add signaling between walreceiver and startup
> process. It indeed isn't much code, and seems pretty safe

Great news! Thanks,
--
dim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: SELECT constant; takes 15x longer on 9.0?
Next: recovery.conf.sample