| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: logical decoding and replication of sequences |
| Date: | 2022-08-07 21:09:53 |
| Message-ID: | CA+hUKGLZfD42Ji-k=BswSFOn8fW85UFS7XrSodiYhuzK9PFETQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 8, 2022 at 7:12 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Sun, Aug 07, 2022 at 03:18:52PM +0200, Tomas Vondra wrote:
> > I'd bet it's about WAL prefetching, not the revert, and the bisect was a
> > bit incorrect, because the commits are close and the failures happen to
> > be rare. (Presumably you first did the bisect and then wrote the patch
> > that reproduces this, right?)
>
> No. I wrote the patch, then used the patch to drive the bisect. With ten
> iterations, commit 2c7ea57 passes 0/10, while 2c7ea57^ passes 10/10. I've now
> tried recovery_prefetch=off. With that, the test passes 10/10 at 2c7ea57.
> Given your observation of a failure at 5dc0418fab2, I agree with your
> conclusion. Whatever the role of 2c7ea57 in exposing the failure on my
> machine, a root cause in WAL prefetching looks more likely.
>
> > Adding Thomas Munro to the thread, he's the WAL prefetching expert ;-)
Thanks for the repro patch and bisection work. Looking...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-08-08 00:27:27 | Re: Cleaning up historical portability baggage |
| Previous Message | Michail Nikolaev | 2022-08-07 19:28:36 | Re: Slow standby snapshot |