Re: Streaming replication and a disk full in primary - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Streaming replication and a disk full in primary
Date
Msg-id y2s603c8f071004141914u577cff34pf91e0412210e65a0@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication and a disk full in primary  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Streaming replication and a disk full in primary  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Streaming replication and a disk full in primary  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Tue, Apr 13, 2010 at 11:56 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Robert Haas wrote:
>> On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>> Why is standby_keep_segments used even if max_wal_senders is zero?
>>>> In that case, ISTM we don't need to keep any WAL files in pg_xlog
>>>> for the standby.
>>> True. I don't think we should second guess the admin on that, though.
>>> Perhaps he only set max_wal_senders=0 temporarily, and will be
>>> disappointed if the the logs are no longer there when he sets it back to
>>> non-zero and restarts the server.
>>
>> If archive_mode is off and max_wal_senders = 0, then the WAL that's
>> being generated won't be usable for streaming anyway, right?
>>
>> I think this is another manifestation of the problem I was complaining
>> about over the weekend: there's no longer a single GUC that controls
>> what type of information we emit as WAL.  In previous releases,
>> archive_mode served that function, but now it's much more complicated
>> and, IMHO, not very comprehensible.
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php
>
> Agreed. We've been trying to deduce from other settings what information
> needs to be WAL-logged, but it hasn't been a great success so it would
> be better to make it explicit than try to hide it.

I've realized another problem with this patch.  standby_keep_segments
only controls the number of segments that we keep around for purposes
of streaming: it doesn't affect archiving at all.  And of course, a
standby server based on archiving is every bit as much of a standby
server as one that uses streaming replication.  So at a minimum, the
name of this GUC is very confusing.  We should also probably think a
little bit about why we feel like it's OK to throw away data that is
needed for SR to work, but we don't feel like we ever want to throw
away WAL segments that we can't manage to archive.

In the department of minor nits, I also don't like the fact that the
GUC is called standby_keep_segments and the variable is called
StandbySegments.  If we really have to capitalize them differently, we
should at least make it StandbyKeepSegments, but personally I think we
should use standby_keep_segments in both places so that it doesn't
take quite so many greps to find all the references.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Win32 timezone matching
Next
From: Tom Lane
Date:
Subject: Re: walreceiver is uninterruptible on win32