Date: Thu, 07 Jul 2022 17:24:59 +0900 (JST)
Message-Id: <20220707.172459.952222721156028881.horikyota.ntt@gmail.com>
To: jchampion@timescale.com
Cc: pryzby@telsasoft.com, tgl@sss.pgh.pa.us, rjuju123@gmail.com,
 jakub.wartak@tomtom.com, pgsql-hackers@lists.postgresql.org
Subject: Re: In-placre persistance change of a relation
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: 
 <CAAWbhmjNGogqd8Vb+HfuUKmkFC_Oyew=CmiobwkxxR-ykSuarQ@mail.gmail.com>
References: <20220331.183318.1550548268473692904.horikyota.ntt@gmail.com>
	<20220331.183634.1085010436469743640.horikyota.ntt@gmail.com>
	<CAAWbhmjNGogqd8Vb+HfuUKmkFC_Oyew=CmiobwkxxR-ykSuarQ@mail.gmail.com>
User-Agent: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Thu_Jul__7_17_24_59_2022_451)--"
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20220707.172459.952222721156028881.horikyota.ntt%40gmail.com>
Precedence: bulk

----Next_Part(Thu_Jul__7_17_24_59_2022_451)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

At Wed, 6 Jul 2022 08:44:18 -0700, Jacob Champion <jchampion@timescale.com> wrote in 
> On Thu, Mar 31, 2022 at 2:36 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > > I don't think this can be commited to 15. So I post the fixed version
> > > then move this to the next CF.
> >
> > Then done. Thanks!
> 
> Hello! This patchset will need to be rebased over latest -- looks like
> b74e94dc27f (Rethink PROCSIGNAL_BARRIER_SMGRRELEASE) and 5c279a6d350
> (Custom WAL Resource Managers) are interfering.

Thank you for checking that!  It got a wider attack by b0a55e4329
(RelFileNumber). The commit message suggests "relfilenode" as files
should be replaced with "relation storage/file" so I did that in
ResetUnloggedRelationsInDbspaceDir.

This patch said that:

>		 * INIT forks are never loaded to shared buffer so no point in
>		 * dropping buffers for such files.

But actually some *buildempty() functions use ReadBufferExtended() for
INIT_FORK. So that's wrong. So, I did that but... I don't like that.
Or I don't like that some AMs leave buffers for INIT fork after. But I
feel I'm misunderstanding here since I don't understand how the INIT
fork can work as expected after a crash that happens before the next
checkpoint flushes the buffers.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

----Next_Part(Thu_Jul__7_17_24_59_2022_451)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="v22-0001-In-place-table-persistence-change.patch"