On Thu, Apr 29, 2010 at 12:17 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Simon Riggs <simon@2ndQuadrant.com> [100429 12:06]:
>
>> Repeating the same thing when its been refuted doesn't help. What you
>> say has not been proposed.
>>
>> If there is a case for HS-off-by-default, make it. If you want to change
>> code, arguing directly against your own position, mentioned many times,
>> we need a reason. How else can we know which argument of yours to
>> believe?
>
> I'm not against HS being on-by-default. But if it is, and the WAL
> it's consuming doesn't have the HS-records by default, then I want PG to
> consider that a problem, make sure I absolutely know it's a problem...
Nobody is proposing otherwise. What Simon and I are proposing is that
if the master is configured to support HS, it comes up on the slave by
default without requiring additional configuration. Now maybe that's
too much spooky action at a distance, but I suspect it IS the behavior
most people will want. If Tom and Heikki get their way and change the
default behavior, it'll just mean (nearly) everyone flips one extra
configuration switch.
> I agree with Heikki that the action-at-a-distance of HS
> trying-to-work-but-maybe-not-this-time-depending-on-the-master is an
> undesirable state...
>
> Like everything else in PG, I'ld like it to "work completely", or tell
> me there is a problem.
>
> That said, I'ld probalby be happy with PG 9 having a "default" config
> of:
>
> wal_mode = hot_standby
> recovery_connections = on
>
> Make it set to generate enough WAL and actually do recovery connections.
That would be a bad idea - there's a significant performance penalty
from setting wal_level to anything other than minimal (just as there
is for turning on archive_mode in 8.4).
> But also make the recover_connections boolean really mean what it s
> called. It's not called try_recovery_connections
Well, sure. But setting work_mem to 1GB doesn't force the planner to
use a gigabyte of memory for every sort, either. It just gives
permission.
...Robert
