From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Date: | 2022-04-01 18:51:58 |
Message-ID: | CA+Tgmobt6ZfS6N2n_a+SUyBrhdQ+GBSS9qqMdfg9HMKAU1Te8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 1, 2022 at 12:22 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> By the way, may I ask how do we fix this? The existing recovery code
> already generates just-to-be-delete files in a real directory in
> pg_tblspc sometimes, and elsewise skip applying WAL records on
> nonexistent heap pages. It is the "mixed" way.
Can you be more specific about where we have each behavior now?
> 1. stop XLogReadBufferForRedo creating a file in nonexistent
> directories then remember the failure (I'm not sure how big the
> impact is.)
>
> 2. unconditionally create all objects required for recovery to proceed..
> 2.1 and igore the failures.
> 2.2 and remember the failures.
>
> 3. Any other?
>
> 2 needs to create a real directory in pg_tblspc. So 1?
I think we could either do 1 or 2. My intuition is that getting 2
working would be less scary and more likely to be something we would
feel comfortable back-patching, but 1 is probably a better design in
the long term. However, I might be wrong -- that's just a guess.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-04-01 19:06:52 | Re: should vacuum's first heap pass be read-only? |
Previous Message | Robert Haas | 2022-04-01 18:39:12 | Re: should vacuum's first heap pass be read-only? |