From: Fujii Masao on 18 Apr 2010 21:58 On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote: >> >>> > I will change the error message. >>> >>> I gave a good deal of thought to trying to figure out a cleaner >>> solution to this problem than just changing the error message and >>> failed. So let's change the error message. Of course I'm not quite >>> sure what we should change it TO, given that the situation is the >>> result of an interaction between three different GUCs and we have no >>> way to distinguish which one(s) are the problem. >> >> "You need all three" covers it. > > Actually you need standby_connections and either archive_mode=on or > max_wal_senders>0, I think. Right. First of all, I wonder why the latter two need to affect the decision of whether additional information is written to WAL for HS. How about just removing XLogIsNeeded() condition from XLogStandbyInfoActive()? 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: Robert Haas on 18 Apr 2010 22:04 On Sun, Apr 18, 2010 at 9:58 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >>> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote: >>> >>>> > I will change the error message. >>>> >>>> I gave a good deal of thought to trying to figure out a cleaner >>>> solution to this problem than just changing the error message and >>>> failed. So let's change the error message. Of course I'm not quite >>>> sure what we should change it TO, given that the situation is the >>>> result of an interaction between three different GUCs and we have no >>>> way to distinguish which one(s) are the problem. >>> >>> "You need all three" covers it. >> >> Actually you need standby_connections and either archive_mode=on or >> max_wal_senders>0, I think. > > Right. > > First of all, I wonder why the latter two need to affect the decision of > whether additional information is written to WAL for HS. How about just > removing XLogIsNeeded() condition from XLogStandbyInfoActive()? Bad idea, I think. If XLogIsNeeded() is returning false and XLogStandbyInfoActive() is returning true, the resulting WAL will still be unusable for HS, at least AIUI. ....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: Fujii Masao on 19 Apr 2010 05:31 On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> First of all, I wonder why the latter two need to affect the decision of >> whether additional information is written to WAL for HS. How about just >> removing XLogIsNeeded() condition from XLogStandbyInfoActive()? > > Bad idea, I think. If XLogIsNeeded() is returning false and > XLogStandbyInfoActive() is returning true, the resulting WAL will > still be unusable for HS, at least AIUI. Probably No. Such a WAL will be usable for HS unless an unlogged operation (e.g., CLUSTER, CREATE TABLE AS SELECT, etc) happens. I think that the occurrence of an unlogged operation rather than XLogIsNeeded() itself must be checked in the standby, it's already been being checked. So just removing XLogIsNeeded() condition makes sense to me. 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: Robert Haas on 19 Apr 2010 17:58 On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >>> First of all, I wonder why the latter two need to affect the decision of >>> whether additional information is written to WAL for HS. How about just >>> removing XLogIsNeeded() condition from XLogStandbyInfoActive()? >> >> Bad idea, I think. If XLogIsNeeded() is returning false and >> XLogStandbyInfoActive() is returning true, the resulting WAL will >> still be unusable for HS, at least AIUI. > > Probably No. Such a WAL will be usable for HS unless an unlogged > operation (e.g., CLUSTER, CREATE TABLE AS SELECT, etc) happens. > I think that the occurrence of an unlogged operation rather than > XLogIsNeeded() itself must be checked in the standby, it's already > been being checked. So just removing XLogIsNeeded() condition makes > sense to me. I think that's a bad idea. Currently we have three possible types of WAL-logging: - just enough for crash recovery (archive_mode=off and max_wal_senders=0) - enough for log-shipping replication (archive_mode=on or max_wal_senders>0, but recovery_connections=off) - enough for log-shipping replication + hot standby (archive_mode=on or max_wal_senders>0, plus recovery_connections=on) I'm not eager to add a fourth category where hot standby works unless you do any of the things that break log-streaming in general. That seems hopelessly fragile and also fairly pointless. ....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
First
|
Prev
|
Pages: 1 2 3 Prev: mremap and bus error Next: [HACKERS] Compile fail, alpha5 & gcc 4.3.3 in elog.c |