Date: Fri, 24 May 2019 19:33:32 -0700
From: Noah Misch <noah@leadboat.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org, 9erthalion6@gmail.com,
	andrew.dunstan@2ndquadrant.com, hlinnaka@iki.fi,
	robertmhaas@gmail.com, michael@paquier.xyz
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Message-ID: <20190525023332.GE1624191@rfd.leadboat.com>
References: <20190514.135910.258194307.horiguchi.kyotaro@lab.ntt.co.jp>
 <20190517065050.GA1298884@rfd.leadboat.com>
 <20190520.155430.215084510.horiguchi.kyotaro@lab.ntt.co.jp>
 <20190521.212948.34357392.horiguchi.kyotaro@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190521.212948.34357392.horiguchi.kyotaro@lab.ntt.co.jp>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

On Mon, May 20, 2019 at 03:54:30PM +0900, Kyotaro HORIGUCHI wrote:
> Following this direction, the attached PoC works *at least for*
> the wal_optimization TAP tests, but doing pending flush not in
> smgr but in relcache.

This task, syncing files created in the current transaction, is not the kind
of task normally assigned to a cache.  We already have a module, storage.c,
that maintains state about files created in the current transaction.  Why did
you use relcache instead of storage.c?

On Tue, May 21, 2019 at 09:29:48PM +0900, Kyotaro HORIGUCHI wrote:
> This is a tidier version of the patch.

> - Move the substantial work to table/index AMs.
> 
>   Each AM can decide whether to support WAL skip or not.
>   Currently heap and nbtree support it.

Why would an AM find it important to disable WAL skip?