Re: standby recovery fails (tablespace related) (tentative patch and discussion)

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 08:18:57
Message-ID: 20220405.171857.1673205520427411283.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 05 Apr 2022 16:38:06 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Tue, 05 Apr 2022 11:16:44 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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 Content-Type Size
v23-0001-Fix-replay-of-create-database-records-on-standby.patch text/x-patch 18.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2022-04-05 09:38:48 Re: Unit tests for SLRU
Previous Message Daniel Gustafsson 2022-04-05 08:11:17 Re: pg_rewind copies