On Thu, Oct 6, 2011 at 7:18 PM, Robert Haas wrote:
> As of 9.1, we already have something very much like this, in the
> opposite direction.
Yes Robert, I wrote it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
Simon Riggs wrote:
> I foresee a function that tells you the delay based on a protocol
> message of 'k' for keepalive.
If the delay you mention is basically a "ping" time or something
similar, that would answer the need I've been on about. We need to
know, based on access to the replica, that
On Thu, Oct 6, 2011 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane wrote:
>>> I'm inclined to think that the way to deal with that is not to force out
>>> useless WAL data, but to add some sort of explicit "I'm alive" heartbeat
>>> signal to the wal
Robert Haas writes:
> On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane wrote:
>> I'm inclined to think that the way to deal with that is not to force out
>> useless WAL data, but to add some sort of explicit "I'm alive" heartbeat
>> signal to the walsender/walreceiver protocol. The hard part of that is
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Do we want this backpatched? If so, suggest just 9.1 and 9.0?
>
> -1 for backpatching; it's more an improvement than a bug fix.
>
> In any case, I think we still need to respond to the point Kevin made
> about how to tell an
On Thu, Oct 6, 2011 at 6:56 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Do we want this backpatched? If so, suggest just 9.1 and 9.0?
>
> -1 for backpatching; it's more an improvement than a bug fix.
OK, works for me.
> In any case, I think we still need to respond to the point Kevin made
> ab
On 06.10.2011 20:58, Tom Lane wrote:
Robert Haas writes:
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane wrote:
I think the point is that a totally idle database should not continue to
emit WAL, not even at a slow rate. There are also power-consumption
objections to allowing the checkpoint process
Robert Haas writes:
> On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane wrote:
>> I think the point is that a totally idle database should not continue to
>> emit WAL, not even at a slow rate. There are also power-consumption
>> objections to allowing the checkpoint process to fire up to no purpose.
>
Simon Riggs writes:
> Do we want this backpatched? If so, suggest just 9.1 and 9.0?
-1 for backpatching; it's more an improvement than a bug fix.
In any case, I think we still need to respond to the point Kevin made
about how to tell an idle master from broken replication. Right now,
you will g
On Thu, Oct 6, 2011 at 5:06 PM, Tom Lane wrote:
> Simon Riggs writes:
>> The current idea is that if there has been no activity then we skip
>> checkpoint. But all it takes is a single WAL record and off we go with
>> another checkpoint. If there hasn't been much WAL activity, there is
>> not muc
Robert Haas wrote:
> Tom Lane wrote:
>> I think the point is that a totally idle database should not
>> continue to emit WAL, not even at a slow rate. There are also
>> power-consumption objections to allowing the checkpoint process
>> to fire up to no purpose.
>
> Hmm, OK. I still think it'
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not entirely sure I understand the rationale, though. I mean, if
>> very little has happened since the last checkpoint, then the
>> checkpoint will be very cheap. In the totally degenerate case Fujii
>> Masao is repor
Robert Haas writes:
> I'm not entirely sure I understand the rationale, though. I mean, if
> very little has happened since the last checkpoint, then the
> checkpoint will be very cheap. In the totally degenerate case Fujii
> Masao is reporting, where absolutely nothing has happened, it should
>
On Thu, Oct 6, 2011 at 12:06 PM, Tom Lane wrote:
> Simon Riggs writes:
>> The current idea is that if there has been no activity then we skip
>> checkpoint. But all it takes is a single WAL record and off we go with
>> another checkpoint. If there hasn't been much WAL activity, there is
>> not mu
Simon Riggs writes:
> The current idea is that if there has been no activity then we skip
> checkpoint. But all it takes is a single WAL record and off we go with
> another checkpoint. If there hasn't been much WAL activity, there is
> not much point in having another checkpoint record since there
On Wed, Oct 5, 2011 at 6:19 AM, Fujii Masao wrote:
> While the system is idle, we skip duplicate checkpoints for some
> reasons. But when wal_level is set to hot_standby, I found that
> checkpoints are wrongly duplicated even while the system is idle.
> The cause is that XLOG_RUNNING_XACTS WAL re
On Wed, Oct 5, 2011 at 1:19 AM, Fujii Masao wrote:
> While the system is idle, we skip duplicate checkpoints for some
> reasons. But when wal_level is set to hot_standby, I found that
> checkpoints are wrongly duplicated even while the system is idle.
> The cause is that XLOG_RUNNING_XACTS WAL rec
Hi,
While the system is idle, we skip duplicate checkpoints for some
reasons. But when wal_level is set to hot_standby, I found that
checkpoints are wrongly duplicated even while the system is idle.
The cause is that XLOG_RUNNING_XACTS WAL record always
follows CHECKPOINT one when wal_level is set
18 matches
Mail list logo
