From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | dilipbalaut(at)gmail(dot)com |
Cc: | robertmhaas(at)gmail(dot)com, hlinnaka(at)iki(dot)fi, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Race condition in recovery? |
Date: | 2021-05-24 04:47:09 |
Message-ID: | 20210524.134709.805985657416573716.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Sun, 23 May 2021 21:37:58 +0530, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote in
> On Sun, May 23, 2021 at 2:19 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > On Sat, May 22, 2021 at 8:33 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> I have created a tap test based on Robert's test.sh script. It
> reproduces the issue. I am new with perl so this still needs some
> cleanup/improvement, but at least it shows the idea.
I'm not sure I'm following the discussion here, however, if we were
trying to reproduce Dilip's case using base backup, we would need such
a broken archive command if using pg_basebackup witn -Xnone. Becuase
the current version of pg_basebackup waits for all required WAL
segments to be archived when connecting to a standby with -Xnone. I
don't bother reconfirming the version that fix took place, but just
using -X stream instead of "none" we successfully miss the first
segment of the new timeline in the upstream archive, though we need to
erase pg_wal in the backup. Either the broken archive command or
erasing pg_wal of the cascade is required to the behavior to occur.
The attached is how it looks like.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-05-24 04:50:13 | Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |
Previous Message | Michael Paquier | 2021-05-24 04:42:26 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |