| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, hlinnaka <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Race condition in recovery? |
| Date: | 2021-06-04 14:37:53 |
| Message-ID: | CA+TgmoaRbfuNhSSGgqah9m0T_Ybshn4aomtSuO8G65c7gCdveQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 4, 2021 at 3:51 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> I could not reproduce this but I think I got the issue, I think I used
> the wrong target LSN in wait_for_catchup, instead of checking the last
> "insert LSN" of the standby I was waiting for last "replay LSN" of
> standby which was wrong. Changed as below in the attached patch.
Yeah, that fixes it for me. Thanks.
With that change, this test reliably passes for me with the fix, and
reliably fails for me without the fix. Woohoo!
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-06-04 14:39:04 | Re: fdatasync performance problem with large number of DB files |
| Previous Message | Nitin Jadhav | 2021-06-04 14:19:21 | Re: when the startup process doesn't |