Date: Wed, 25 Aug 2021 19:29:54 -0400
From: "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>
To: Jakub Wartak <Jakub.Wartak@tomtom.com>
Cc: "Bossart, Nathan" <bossartn@amazon.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	"mengjuan.cmj@alibaba-inc.com" <mengjuan.cmj@alibaba-inc.com>
Subject: Re: prevent immature WAL streaming
Message-ID: <202108252329.oqhdllz2iq73@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <VI1PR0701MB69608F806BD102C8B4C3C6FDF6C69@VI1PR0701MB6960.eurprd07.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202108252329.oqhdllz2iq73%40alvherre.pgsql>
Precedence: bulk

On 2021-Aug-25, Jakub Wartak wrote:

> In order to get reliable reproducer and get proper the fault injection
> instead of playing with really filling up fs, apparently one could
> substitute fd with fd of /dev/full using e.g. dup2() so that every
> write is going to throw this error too:

Oh, this is a neat trick that I didn't know about.  Thanks.

> After restarting master and inspecting standby - in all of those above
> 3 cases - the standby didn't inhibit the "invalid contrecord length"
> at least here, while without corruption this v02 patch it is
> notorious. So if it passes the worst-case code review assumptions I
> would be wondering if it shouldn't even be committed as it stands
> right now.

Well, Nathan is right that this patch isn't really closing the hole
because we aren't tracking segment boundaries that aren't "earliest" nor
"latest" at the moment of registration.  The simplistic approach seems
okay for the archive case, but not for the replication case.

I also noticed today (facepalm) that the patch doesn't work unless you
have archiving enabled, because the registration code is only invoked
when XLogArchivingActive().  Doh.  This part is easy to solve.  The
other doesn't look easy ...

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/