From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per |
Date: | 2010-04-06 10:11:32 |
Message-ID: | 877hok7uwb.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-04-06 10:50:57 | pgsql: Change some debug ereports to elogs, as requested by translation |
Previous Message | Simon Riggs | 2010-04-06 10:04:31 | Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-04-06 10:25:13 | Re: pending patch: Re: Streaming replication and pg_xlogfile_name() |
Previous Message | Simon Riggs | 2010-04-06 10:04:31 | Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per |