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 13:37 On Thu, 2010-04-29 at 13:03 -0400, Tom Lane wrote: > There is not only a performance penalty I've asked for evidence that recovery is any slower as a result of HS. If we had some, I'm guessing we'd be tuning rather than discussing this. > Enabling these switches turns on a whole lot of code that, with all > due respect to those who have worked on it, is absolutely positively > guaranteed to be full of bugs. I understand that view and don't take offence at all, thank you for your concern. I wish to take seriously the possibility you may be correct, so I want to squash unfounded rumours that will scare people into keeping HS turned off, because that will keep the bugs in, rather than flush them out so we can fix them. Can we keep the default=on during beta and collect evidence before making a final decision at release? -- 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: "Joshua D. Drake" on 29 Apr 2010 13:42 On Thu, 2010-04-29 at 13:03 -0400, Tom Lane wrote: > There is not only a performance penalty, but a reliability penalty. > Enabling these switches turns on a whole lot of code that, with all > due respect to those who have worked on it, is absolutely positively > guaranteed to be full of bugs. Not all of which are going to be flushed > out during beta. If we ship 9.0 with these things on by default, it > will result in an immediate reliability downgrade for installations that > are simply doing what they did before and not even interested in HS/SR. > > Maybe by 9.1 or 9.2 it would be sensible to have some of this code > turned on by default. But it is absolutely not in keeping with this > project's mindset or historical practice to enable it by default now. > > regards, tom lane +1 Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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 13:39 On Thu, 2010-04-29 at 12:16 -0500, Kevin Grittner wrote: > Simon Riggs <simon(a)2ndQuadrant.com> wrote: > > > Which is what everybody has requested. > > You continue to use the term "everybody" rather loosely. Sorry, that was imprecise, I didn't mean to exaggerate. -- 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 14:00 On Thu, 2010-04-29 at 19:55 +0300, Heikki Linnakangas wrote: > And Aidan and me are human > beings, included in "everybody". Yes, that was too loose. I dislike that kind of argument and I'm sorry that slipped in here. > You know that there is cases where it causes problems in the standby, > even ignoring the possibility of bugs. For example, if you increase > max_connections in the master, the standby will abort. That behaviour was suggested by you. I don't think its anywhere near necessary that it does that and would like to remove that restriction. The likelihood we'll ever run out of slots is small even with large increases in max_connections. Example: if we increase from 100 to 500 we'd only hit the limit if we had all 500 connections on the master simultaneously running write transactions with an average 12 subtransactions each. > It's safer to run > with recovery_connections off if you don't need the feature. Presumably your advice is also that people should not run with Streaming Replication if they don't need that feature? And that we should also have an enable_joinremoval flag so the risk it poses can be minimized? You didn't argue this way with regard to vacuum/FSM in 8.4, which was much more critical; we're just talking about a standby server. -- 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 14:24
On Thu, 2010-04-29 at 13:01 -0500, Kevin Grittner wrote: > Simon Riggs <simon(a)2ndQuadrant.com> wrote: > > > I've asked for evidence that recovery is any slower as a result of > > HS. > > Can you quantify the impact on the number of bytes written to WAL > when switching from the archiving level to the hot standby level? Sure, done that a few times. Extra WAL data is written for these actions, listed in order of increasing size * commit records contain a variable length list of relcacheinvalidations, mostly applies only to DDL * one extra WAL record in most VACUUMs, fairly small, optimised away in some cases * a transaction issues more than 64 subtransactions it will issue a record approx 256 bytes plus header * 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 -- 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 |