On Wed, Oct 5, 2011 at 1:19 AM, Fujii Masao masao.fu...@gmail.com 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
On Wed, Oct 5, 2011 at 6:19 AM, Fujii Masao masao.fu...@gmail.com 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
Simon Riggs si...@2ndquadrant.com 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
On Thu, Oct 6, 2011 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us 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.
On Thu, Oct 6, 2011 at 5:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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.
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane t...@sss.pgh.pa.us 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
On 06.10.2011 20:58, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lanet...@sss.pgh.pa.us 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
On Thu, Oct 6, 2011 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Oct 6, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs si...@2ndquadrant.com 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
On Thu, Oct 6, 2011 at 7:18 PM, Robert Haas robertmh...@gmail.com 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
17 matches
Mail list logo
