From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | dilipbalaut(at)gmail(dot)com |
Cc: | robertmhaas(at)gmail(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, michael(at)paquier(dot)xyz, rjuju123(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Date: | 2022-04-05 02:16:44 |
Message-ID: | 20220405.111644.594404600058854751.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 4 Apr 2022 21:14:27 +0530, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote in
> On Mon, Apr 4, 2022 at 2:25 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > At Mon, 04 Apr 2022 17:29:48 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-04-05 02:19:45 | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Previous Message | Michael Paquier | 2022-04-05 02:12:19 | Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? |