Prev: [HACKERS] pg_filedump strangeness
Next: pgsql: Forbid using pg_xlogfile_name() andpg_xlogfile_name_offset()
From: Robert Haas on 12 Apr 2010 09:04
On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
<heikki.linnakangas(a)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

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

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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

--
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: Heikki Linnakangas on 15 Apr 2010 02:54
Robert Haas wrote:
> 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.

Hmm, I guess streaming_keep_segments would be more accurate. Somehow
doesn't feel as good otherwise, though. Any other suggestions?

> 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.

Failure to archive is considered more serious, because your continuous
archiving backup becomes invalid if we delete a segment before it's
archived. And a streaming standby server can catch up using the archive
if it falls behind too much. Plus the primary doesn't know how many
standby servers there is, so it doesn't know which segments are still
needed for SR.

> 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.

Well, it's consistent with checkpoint_segments/CheckPointSegments. There
is no consistent style on naming the global variables behind GUCs. If
you feel like changing it though, I won't object.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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: Alvaro Herrera on 15 Apr 2010 10:39
Robert Haas escribi�:

> 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.

+1, using both names capitalized identically makes the code easier to navigate.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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  |  Next  |  Last
Pages: 1 2 3
Prev: [HACKERS] pg_filedump strangeness
Next: pgsql: Forbid using pg_xlogfile_name() andpg_xlogfile_name_offset()