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)
|
Список | 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 по дате отправления: