pgsql: MakeCheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: pgsql: Make CheckRequiredParameterValues()depend upon correct
Next: [HACKERS] Schema.Table.Col resolution seems broken in Alpha5
From: Simon Riggs on 29 Apr 2010 12:02 On Thu, 2010-04-29 at 18:40 +0300, Heikki Linnakangas wrote: > It's error-prone to control what happens in the standby from the master. > That's the "action at a distance" effect I mentioned earlier. The master > should be configured in the master, and each standby should configured > in the standby. 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? -- Simon Riggs www.2ndQuadrant.com -- 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: Simon Riggs on 29 Apr 2010 12:10 On Thu, 2010-04-29 at 11:37 -0400, Aidan Van Dyk wrote: > * Simon Riggs <simon(a)2ndQuadrant.com> [100429 11:24]: > > > > What is the reason for the *extra* "off" switch? Why two? Why "off" > > twice? > > Because I run a PITR slave off a WAL archive... And I'm going to > continue to try and use this setup... I expect to try and experiment > with wal-streaming too when everything is up to 9, and be a little upset > when the "old faithfull" backup I've got and am betting my job on > suddenly starts acting differentlyl, or accepting connections and > causing my db clients to start thowing errors because I'm trying to get > a streaming replication w/ hot standby up on a *different* slave... > > It's all about the path of least *suprise*. My "least suprise" would > have been that a similar config I have now with my PITR slaves would > pretty much still work, and not suddenly start accepting connections, > and even worse, at some later date when I've already verified that it > was doing what I expected with the configuration. If people upgrade to 9.0 and then are surprised that the features listed are actually available, I too would be surprised. If we all believe that these radical surprises are a problem, then we should also turn off join removal and loads of other features in 9.0 that will also cause surprises. HS is the most requested feature across multiple polls and *not* being able to connect to it is likely to come as a huge surprise to many people. HS is just as secure as the main database. There is no big use case for "run with HS turned off". Everybody wants it on, as long as it works and don't cause problems. So far, there is no evidence to make anyone think that it would and I wish to avoid that implication. Heikki previously argued strongly against having any switch at all, so it could be turned on all the time. Nothing's changed. -- Simon Riggs www.2ndQuadrant.com -- 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: Aidan Van Dyk on 29 Apr 2010 12:17 * 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... 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. But also make the recover_connections boolean really mean what it s called. It's not called try_recovery_connections a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
From: Aidan Van Dyk on 29 Apr 2010 12:23 * Simon Riggs <simon(a)2ndQuadrant.com> [100429 12:14]: HS is the most requested feature across multiple polls and *not* being > able to connect to it is likely to come as a huge surprise to many > people. HS is just as secure as the main database. > > There is no big use case for "run with HS turned off". Everybody wants > it on, as long as it works and don't cause problems. So far, there is no > evidence to make anyone think that it would and I wish to avoid that > implication. > > Heikki previously argued strongly against having any switch at all, so > it could be turned on all the time. Nothing's changed. I'm not arguing against having it on by default. What I'm against (and that's strong, it should probably be "prefer not to have") is having it configured "on", but having it "not work". If it's been configured to run in a state it can't, I would prefer it didn't run, not that it ran, but in a slightly different state... But I know that's just a preference... And one from an old-school unix admin too... a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
From: Simon Riggs on 29 Apr 2010 13:03
On Thu, 2010-04-29 at 11:48 -0500, Kevin Grittner wrote: > Simon Riggs <simon(a)2ndQuadrant.com> wrote: > > > There is no big use case for "run with HS turned off". > > There was mention of running the live database and a warm standby, > with a connection pooler pointed to both so that it could > automatically reconnect on failover. pgpool already copes by design and has been working against HS for months. If the connection pooler doesn't have some way of knowing the server is a standby, then it will try to connect and fail, which presumably it would retry. This seems like a hypothetical connection pooler rather than a real one, to me. HS can continue to be used with people's existing Warm Standby setup, just now you can read the database as well. Which is what everybody has requested. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |