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.171857.1673205520427411283.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)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
At Tue, 05 Apr 2022 16:38:06 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> 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.
> 
> This is the first cut of the above.

It had an unused variable for Windows.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pg_rewind copies
Next
From: Aleksander Alekseev
Date:
Subject: Re: Unit tests for SLRU