Re: standby recovery fails (tablespace related) (tentative patch and discussion) - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id 20220405.163806.716548871041426622.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
At Tue, 05 Apr 2022 11:16:44 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> 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.

Okay, it was my thinko.  But I faced another obstacle.

This is the first cut of the above.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Andy Fan
Date:
Subject: Re: Window Function "Run Conditions"