From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Andrew Dunstan <andrew@dunslane.net>,
        "Bossart,
    Nathan" <bossartn@amazon.com>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
        "andres@anarazel.de" <andres@anarazel.de>,
        "masao.fujii@oss.nttdata.com" <masao.fujii@oss.nttdata.com>,
        "pgsql-hackers@lists.postgresql.org"
 <pgsql-hackers@lists.postgresql.org>,
        "mengjuan.cmj@alibaba-inc.com" <mengjuan.cmj@alibaba-inc.com>,
        "Jakub.Wartak@tomtom.com" <Jakub.Wartak@tomtom.com>,
        Ryo Matsumura <matsumura.ryo@fujitsu.com>
Subject: Re: prevent immature WAL streaming
In-reply-to: <202109301432.mou5kmj3h2r6@alvherre.pgsql>
References: <202109301432.mou5kmj3h2r6@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Thu, 30 Sep 2021 11:32:57 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3080925.1633018374.1@sss.pgh.pa.us>
Date: Thu, 30 Sep 2021 12:12:54 -0400
Message-ID: <3080926.1633018374@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3080926.1633018374%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Sep-30, Tom Lane wrote:
>> There's still the issue of these tests overriding postgresql.conf
>> entries made by init(), but maybe we can live with that?

> I vote to at least have has_archiving=>1 set wal_level=replica, and
> potentially max_wal_senders=2 too (allows pg_basebackup).

I think this requires a bit more investigation.  I looked quickly
through the pre-existing tests that set has_archiving=>1, and every
single one of them also sets allows_streaming=>1, which no doubt
explains why this issue hasn't come up before.  So now I'm wondering
if any of those other tests is setting allows_streaming only because
of this configuration issue.

More to the point, since we've not previously used the combination
of has_archiving without allows_streaming, I wonder exactly how
we want to define it to work.  I'm not really convinced that it
should be defined as "allows basebackup even though replication
is supposed to be off".

Perhaps a compromise could be to invent a third option
"allows_basebackup", so that init() actually knows what's going on?

			regards, tom lane