Date: Mon, 12 Dec 2022 12:06:36 +0900 (JST)
Message-Id: <20221212.120636.567365638124623176.horikyota.ntt@gmail.com>
To: bharath.rupireddyforpostgres@gmail.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when
 possible
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <20221212.115717.1183698540772933396.horikyota.ntt@gmail.com>
References: 
 <CALj2ACXKKK=wbiG5_t6dGao5GoecMwRkhr7GjVBM_jg54+Na=Q@mail.gmail.com>
	<20221212.115717.1183698540772933396.horikyota.ntt@gmail.com>
User-Agent: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20221212.120636.567365638124623176.horikyota.ntt%40gmail.com>
Precedence: bulk

At Mon, 12 Dec 2022 11:57:17 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> This patch copies the bleeding edge WAL page without recording the
> (next) insertion point nor checking whether all in-progress insertion
> behind the target LSN have finished. Thus the copied page may have
> holes.  That being said, the sequential-reading nature and the fact
> that WAL buffers are zero-initialized may make it work for recovery,
> but I don't think this also works for replication.

Mmm. I'm a bit dim. Recovery doesn't read concurrently-written
records. Please forget about recovery.

> I remember that the one of the advantage of reading the on-memory WAL
> records is that that allows walsender to presend the unwritten
> records. So perhaps we should manage how far the buffer is filled with
> valid content (or how far we can presend) in this feature.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center