Re: Recent 027_streaming_regress.pl hangs

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recent 027_streaming_regress.pl hangs
Date: 2024-03-14 03:16:24
Message-ID: CA+hUKGLHUrFnzi4NOcH_WNaVPnjPqPgENY8QjUMSvOPd94QWCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 14, 2024 at 3:27 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Hmm. Perhaps 8af25652489? That looks like the closest thing in the
> list that could have played with the way WAL is generated, hence
> potentially impacting the records that are replayed.

Yeah, I was wondering if its checkpoint delaying logic might have
got the checkpointer jammed or something like that, but I don't
currently see how. Yeah, the replay of bulk newpages could be
relevant, but it's not exactly new technology. One thing I wondered
about is whether the Perl "wait for catchup" thing, which generates
large volumes of useless log, could be somehow changed to actually
show the progress after some time. Something like "I'm still waiting
for this replica to reach LSN X, but it has so far only reported LSN
Y, and here's a dump of the WAL around there"?

> 93db6cbda03, efa70c15c74 and 818fefd8fd4 came to mind, but they touch
> unrelated territory.

Hmm.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2024-03-14 04:20:41 Inconsistent printf placeholders
Previous Message Masahiko Sawada 2024-03-14 03:06:59 Re: Improve eviction algorithm in ReorderBuffer