Re: Avoiding adjacent checkpoint records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding adjacent checkpoint records
Date: 2012-06-07 17:20:33
Message-ID: 10514.1339089633@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... It's better to have a few unnecessary
> checkpoints than to risk losing somebody's data, especially since the
> unnecessary checkpoints only happen with wal_level=hot_standby, but
> the data loss risk exists for everyone.

Yeah, that's another point here: the benefit of the patch accrues to
a different set of people than the ones paying the penalty. If you've
got hot standby enabled, presumably you are replicating to at least one
slave and so the prospect of data loss via WAL loss is mitigated for you.

I also note that the other work done in 9.2 to reduce idle-system load
did not address replication configurations at all; I think we still have
time-driven wakeups in walsender and walreceiver for instance. So I'd
rather revert the patch now, and consider that a better fix will be part
of a future round of work to reduce the idle-system load in replication
setups.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-06-07 17:24:15 Re: XLog changes for 9.3
Previous Message Kevin Grittner 2012-06-07 17:15:26 Re: XLog changes for 9.3