pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: "Kevin Grittner" on 29 Apr 2010 14:47 Simon Riggs <simon(a)2ndQuadrant.com> wrote: > [most significant extra WAL logging for hot standby is:] > * one extra WAL record every checkpoint, containing a full current > snapshot's worth of running xids 100-400 bytes typically, could go > up from there to 4000 bytes in very extreme write workloads that > also have many, many subtransactions The most convincing evidence that there's no significant performance hit for those not needing the feature (and not a bad thing from a testing point of view anyway) would be for someone to run some benchmarks comparing the archive and hot_standby logging levels, with no archive script or SR. If that hasn't been done yet, maybe you could find somebody who knows his way around pgbench-tools, who could construct a reasonable test and produce graphs and all that cool stuff. ;-) IMO, isolating the cost of generating and writing the extra WAL would be very valuable, and it would be reassuring to know that it worked with a large number of clients without exposing any dire race conditions. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Apr 2010 12:41 On Thu, Apr 29, 2010 at 12:17 PM, Aidan Van Dyk <aidan(a)highrise.ca> wrote: > * Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Apr 2010 16:18 Okay, this thread seems to be running out of steam, and we are running out of hours before the beta1 wrap. I am going to take it on my own authority to do the following: * rename recovery_connections to hot_standby (and the underlying variable from XLogRequestRecoveryConnections to something like EnableHotStandby); * change its default value to 'off'. I believe the only other code changes needed for beta1 are the pg_start/stop_backup error check changes that Heikki proposed at <4BD953A6.70409(a)enterprisedb.com>. If he doesn't commit that within an hour or two, I will. This train is leaving the station. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Apr 2010 16:33
On Thu, Apr 29, 2010 at 4:18 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > This train is leaving the station. An enthusiastic +1 for train departure. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |