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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Дата
Msg-id CA+Tgmobt6ZfS6N2n_a+SUyBrhdQ+GBSS9qqMdfg9HMKAU1Te8Q@mail.gmail.com
обсуждение исходный текст
Ответ на 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>)
Список pgsql-hackers
On Fri, Apr 1, 2022 at 12:22 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: should vacuum's first heap pass be read-only?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: should vacuum's first heap pass be read-only?