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: Alvaro Herrera on 27 Apr 2010 15:20 Heikki Linnakangas escribi�: > Tom Lane wrote: > > How about putting the enum {} declaration in xlog.h, and making the > > field in pg_control.h just be declared "int"? > > I tried that at first, but the problem was with pg_controldata.c. In > bin/. I wanted it to print wal_mode in human-readable format, so it > needed the values of the enum from somewhere. I tried to "#include > <access/xlog.h>" in pg_controlinfo.c, but got a bunch of errors. Hmm, AFAICS the problem with controldata is that it uses postgres_fe.h instead of postgres.h. It's a bit of a stretch to use the latter, but maybe that's a better solution? After all, it *is* poking into the backend internals. I know I had to hack around pg_controldata some time ago (I don't recall what for) and found that it could be cleaned up like this. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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: Alvaro Herrera on 27 Apr 2010 19:28 Tom Lane escribi�: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > Hmm, AFAICS the problem with controldata is that it uses postgres_fe.h > > instead of postgres.h. It's a bit of a stretch to use the latter, but > > maybe that's a better solution? After all, it *is* poking into the > > backend internals. > > I seem to recall that Solaris had problems with that due to dtrace > support or something? Hmm, I wonder if you're referring to the fact that Zdenek wanted to restructure the headers for something? I don't know if this was because of compiler issues or the binary migration tool he was working on. > However, we are doing it in pg_resetxlog, so I suppose it's ok for > pg_controldata as well. I hadn't noticed that, but yes. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 28 Apr 2010 04:00 On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote: > * renamed wal_mode to wal_level I'm wondering whether this should be a list rather than an enum? If we add something in the future that adds more info to WAL but doesn't fit the one-dimensional model this implements then we could be in trouble. Should this be e.g. wal_xxxx = feature2, feature3 e.g. wal_xxxx = feature3 e.g. wal_xxxx = feature1 recognising that some features require other features, so as an example feature2 requires and implies feature1. The word "level" implies a one-dimensionality that "mode" did not and I feel a little uncertain about that term. Other words: attributes, features, contents, info, options. Hmm, wal_options sounds OK. Anyway, just throwing out some ideas to make sure we're doing the right thing with this. -- 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 28 Apr 2010 10:59 On Wed, 2010-04-28 at 10:19 -0400, Tom Lane wrote: > I'm a bit suspicious of going in this direction, mainly because > DateStyle has been such a PITA over the years. LOL. Man that's a pain. That's an unfair brush though! -- 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 04:18
On Thu, 2010-04-29 at 10:55 +0300, Heikki Linnakangas wrote: > Should we change the default to recovery_connections=off ? It is a quite > big change in default behavior over previous releases that hot standby > is enabled by default, so maybe that would be the right thing to do anyway. > > Or maybe add a hint to the above, "disable hot standby by setting > recovery_connections=off, or set wal_level='hot_standby' in the primary" I've been waiting for this suggestion, a clear knock-on effect from your earlier changes. If we just have a static default its bad either way. The most sensible way is to make the default act intelligently depending upon what it finds in the control file. If WAL contains hot_standby info, then recovery_connections should be on by default, though can be turned off explicitly if required. If WAL does not contain hot_standby info we then we throw a WARNING and continue as if recovery_connections = off, or if recovery_connections is specified explicitly then we should throw an ERROR so that the user knows it won't be possible to use this. I think that means we'd need to change recovery_connections to have 2 or 3 values, but non-boolean: recovery_connections = auto (default) | off or recovery_connections = auto (default) | on | off and I would suggest removing it from postgresql.conf.sample -- 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 |