pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: Tom Lane on 27 Apr 2010 11:42 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Ok, here's a patch that includes the changes to add new wal_mode GUC > (http://archives.postgresql.org/message-id/4BD581A6.60602(a)enterprisedb.com), I haven't read this in any detail, but why does it add inclusion of pg_control.h to xlog.h? I don't see any reason for that in the actual changes in xlog.h. 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: Tom Lane on 27 Apr 2010 14:16 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> I haven't read this in any detail, but why does it add inclusion of >> pg_control.h to xlog.h? I don't see any reason for that in the actual >> changes in xlog.h. > I put the enum for wal_mode to pg_control.h, so that it's available to > pg_controlinfo.c without #including xlog.h there. The > XLogArchivingActive() macro in xlog.h needs the enum values: Oh, I see. > I'm all ears for better suggestions, I didn't like that much either. How about putting the enum {} declaration in xlog.h, and making the field in pg_control.h just be declared "int"? I'm not sure declaring it as enum is a great idea anyway, since that makes the on-disk representation dependent on a compiler's whim as to how wide the enum will be. 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: Tom Lane on 27 Apr 2010 19:00 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? However, we are doing it in pg_resetxlog, so I suppose it's ok for pg_controldata as well. 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: Fujii Masao on 28 Apr 2010 05:54 On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Ok, did that. Here's an updated patch: > + During recovery, specifies whether or not you can connect and run > + queries to enable <xref linkend="hot-standby">. The default value is > + <literal>on</literal>. > + This parameter can only be set at server start. It is ignored when > + not in standby mode. In the patch, I was not able to find any change which ignores recovery_connections when standby_mode is OFF. And that change spoils the combination of pg_standby and HS? We drop the support for it? > * renamed wal_mode to wal_level We should replace "mode" with "level" in the document of wal_level parameter as follows? @@ -1368,9 +1368,9 @@ SET ENABLE_SEQSCAN TO OFF; read-only queries on a standby server. This parameter can only be set at server start. </para> <para> - In <literal>minimal</> mode, WAL-logging of some bulk operations, like + In <literal>minimal</> level, WAL-logging of some bulk operations, like <command>CREATE INDEX</>, <command>CLUSTER</> and <command>COPY</> on a table that was created or truncated in the same transaction can be safely skipped, which can make those operations much faster (see <xref linkend="populate-pitr">). But minimal WAL does not contain @@ -1379,15 +1379,15 @@ SET ENABLE_SEQSCAN TO OFF; WAL archiving (<xref linkend="guc-archive-mode">) and streaming replication. </para> <para> - In <literal>hot_standby</> mode, the same information is logged as - in <literal>archive</> mode, plus information needed to reconstruct + In <literal>hot_standby</> level, the same information is logged as + in <literal>archive</> level, plus information needed to reconstruct the status of running transactions from the WAL. To enable read-only queries on a standby server, <varname>wal_level</> must be set to <literal>hot_standby</> on the primary. It is thought that there is little measurable difference in performance from using - <literal>hot_standby</> mode over <literal>archive</>, so feedback + <literal>hot_standby</> level over <literal>archive</>, so feedback is welcome if any production impacts are noticeable. </para> </listitem> </varlistentry> Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 28 Apr 2010 09:38
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > At commit, should I bump catversion, or PG_CONTROL_VERSION, or both? The > patch replaces the unlogged-operation WAL record with a record > containing current parameter values, and it changes pg_control. I'm > guessing both. You *must* bump PG_CONTROL_VERSION because the content of pg_control changed. The correct way to reflect a change in WAL contents is to bump the WAL page magic number. I don't see any change here in either system catalog contents or user table contents, so I see no need to touch catversion. 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 |