public inbox for [email protected]  

help / color / mirror / Atom feed

From: Kyotaro Horiguchi <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date: Tue, 05 Apr 2022 11:16:44 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFiTN-tvxa02H663TaP+-UE=gn9wS_3h15AoqA2=h2aBzkdnEA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CAFiTN-tvxa02H663TaP+-UE=gn9wS_3h15AoqA2=h2aBzkdnEA@mail.gmail.com>

At Mon, 4 Apr 2022 21:14:27 +0530, Dilip Kumar <[email protected]> wrote in 
> On Mon, Apr 4, 2022 at 2:25 PM Kyotaro Horiguchi
> <[email protected]> wrote:
> >
> > At Mon, 04 Apr 2022 17:29:48 +0900 (JST), Kyotaro Horiguchi <[email protected]> wrote in
> > > I haven't found how the patch caused creation of a relation file that
> > > is to be removed soon.  However, I find that v19 patch fails by maybe
> > > due to some change in Cluster.pm.  It takes a bit more time to check
> > > that..
> >
> > I was a bit away, of course the wal-logged create database interfares
> > with the patch here. But I haven't found that why it stops creating
> > database directory under pg_tblspc.
> 
> I did not understand what is the exact problem here, but the database
> directory and the version file are created under the default
> tablespace of the target database.  However, other than the default
> tablespace of the database, the database directory will be created
> along with the smgrcreate() so that we do not create an unnecessary
> directory under the tablespace where we do not have any data to be
> copied.

Thanks. Yeah, I suspected something like that but I didn't find a
difference in the code I suspected to be related with, but it's was
wrong.  I took wrong steps trying to reveal that state and faced the
wrong error message. With the correct steps, I could see that
Storage/CREATE creates pg_tblspc/<directory>.

So, if we create missing tablespace directory, we have no way
otherthan creating it directly in pg_tblspc, which is violating the
rule that there shouldn't be real directory in pg_tblspc (when
allow_in_place_tablespaces is false).

So, I have the following points in my mind for now.

- We create the directory "since we know it is just tentative state".

- Then, check that no directory in pg_tblspc when reaching consistency
  when allow_in_place_tablespaces is false.

- Leave the log_invalid_page() mechanism alone as it is always result
  in a corrpt page if a differential WAL record is applied on a newly
  created page that should have been exist.

However, while working on it, I found that I found that recovery faces
missing tablespace directories *after* reaching consistency.  I'm
examining that further.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox