Re: remove wal_level archive - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: remove wal_level archive
Date
Msg-id 56D4EA36.6030301@gmx.net
Whole thread Raw
In response to Re: remove wal_level archive  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: remove wal_level archive  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2/8/16 7:34 AM, Michael Paquier wrote:
> Shouldn't backup.sgml be updated as well? Here is the portion that I
> am referring to:
>     To enable WAL archiving, set the <xref linkend="guc-wal-level">
>     configuration parameter to <literal>archive</> or higher,
>     <xref linkend="guc-archive-mode"> to <literal>on</>,
>
>          But minimal WAL does not contain enough information to reconstruct the
> -        data from a base backup and the WAL logs, so <literal>archive</> or
> +        data from a base backup and the WAL logs, so <literal>replica</> or
>          higher must be used to enable WAL archiving
>          (<xref linkend="guc-archive-mode">) and streaming replication.
>         </para>

Checked for leftovers again and fixed one.

>         <para>
> -        In <literal>hot_standby</> level, the same information is logged as
> -        with <literal>archive</>, plus information needed to reconstruct
> -        the status of running transactions from the WAL. To enable read-only
> As the paragraph about the difference between hot_standby and archive
> is removed, I think that it would be better to mention that setting
> wal_level to replica allows to reconstruct data from a base backup and
> the WAL logs, *and* to run read-only queries when hot_standby is
> enabled.

Well, I think that is really only of historical interest.  The
assumption is, as long as hot_standby = on, you can run read-only
queries.  The WAL level is taken completely out of the mental
consideration, because if you have replicate at all, it's good enough.
That is part of the point of this patch.

>
> -               if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
> +               if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
> Upthread it was mentioned that switching to an approach where enum
> values are directly listed would be better. The target of an extra
> patch on top of this one?

I'm not sure what is meant by that.

>
> -       if (wal_level < WAL_LEVEL_ARCHIVE)
> -               ereport(ERROR,
> -
> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> -                                errmsg("replication slots can only be
> used if wal_level >= archive")));
> We should still forbid the creation of replication slots if wal_level = minimal.

I think I took this out because you actually can't get to that check,
but I put it back in because it seems better for clarity.


Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: remove wal_level archive
Next
From: Tom Lane
Date:
Subject: Re: create opclass documentation outdated