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

Поиск
Список
Период
Сортировка
От Paul Guo
Тема Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Дата
Msg-id CABQrizcEQ5uoM=M0Mf2kMr-PAQUVvvhwO9cy4PHkaYG=XSaciw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Aug 11, 2021 at 4:56 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Aug 5, 2021 at 6:20 AM Paul Guo <guopa@vmware.com> wrote:
> > Rebased.
>
> The commit message for 0001 is not clear enough for me to understand
> what problem it's supposed to be fixing. The code comments aren't
> really either. They make it sound like there's some problem with
> copying symlinks but mostly they just talk about callbacks, which
> doesn't really help me understand what problem we'd have if we just
> didn't commit this (or reverted it later).

Thanks for reviewing. Let me explain a bit. The patch series includes
four patches.

0001 and 0002 are test changes for the fix (0003).
   - 0001 is the test framework change that's needed by 0002.
   - 0002 is the test for the code fix (0003).
0003 is the code change and the commit message explains the issue in detail.
0004 as said is a small enhancement which is a bit independent of the
previous patches.

Basically the issue is that without the fix crash recovery might fail
relevant to tablespace.
Here is the log after I run the tests in 0001/0002 without the 0003 fix.

2021-08-04 10:00:42.231 CST [875] FATAL:  could not create directory
"pg_tblspc/16385/PG_15_202107261/16390": No such file or directory
2021-08-04 10:00:42.231 CST [875] CONTEXT:  WAL redo at 0/3001320 for
Database/CREATE: copy dir base/1 to
pg_tblspc/16385/PG_15_202107261/16390


>
> I am not really convinced by Álvaro's claim that 0004 is a "fix"; I
> think I'd call it an improvement. But either way I agree that could
> just be committed.
>
> I haven't analyzed 0002 and 0003 yet.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
>


--
Paul Guo (Vmware)



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Small documentation improvement for ALTER SUBSCRIPTION
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side