From: Fujii Masao on
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
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
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
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