Re: Streaming replication and a disk full in primary

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and a disk full in primary
Date: 2010-04-15 02:14:13
Message-ID: y2s603c8f071004141914u577cff34pf91e0412210e65a0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 13, 2010 at 11:56 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-04-15 02:17:39 Re: walreceiver is uninterruptible on win32
Previous Message Tom Lane 2010-04-15 01:48:17 Re: Win32 timezone matching