Re: Keepalive for max_standby_delay - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Keepalive for max_standby_delay
Date
Msg-id 26977.1275579283@sss.pgh.pa.us
Whole thread Raw
In response to Keepalive for max_standby_delay  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Keepalive for max_standby_delay  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
>> Well, if the slave can't keep up, that's a separate problem. �It will
>> not fail to keep up as a result of the transmission mechanism.

> No, I mean if the slave is paused due to a conflict. Does it stop
> reading data from the master or does it buffer it up on disk? If it
> stops reading it from the master then the effect is the same as if the
> slave stopped "requesting" data even if there's no actual request.

The data keeps coming in and getting dumped into the slave's pg_xlog.
walsender/walreceiver are not at all tied to the slave's application
of WAL.  In principle we could have the code around max_standby_delay
notice just how far behind it's gotten and adjust the delay tolerance
based on that; but I think designing a feedback loop for that is 9.1
material.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Did we really want to force an initdb in beta2?
Next
From: Bruce Momjian
Date:
Subject: Re: functional call named notation clashes with SQL feature