Re: pg_basebackup WAL streamer shutdown is bogus - leading to slow tests

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_basebackup WAL streamer shutdown is bogus - leading to slow tests
Date: 2022-01-17 13:50:27
Message-ID: CABUevEwGNObu4iddyQizWMEk8EBZ+oikMdk+BXEqaaC=zVNRjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2022 at 12:31 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2022-01-16 15:28:00 -0800, Andres Freund wrote:
> > I hacked that up last night. And a fix or two later, it seems to be
> > working. What I'd missed at first is that the event needs to be reset in
> > reached_end_position(), otherwise we'll busy loop.

You can create the event with bManualReset set to False to avoid that,
no? With this usecase, I don't really see a reason not to do that
instead?

> > I wonder if using a short-lived event handle would have dangers of missing
> > FD_CLOSE here as well? It'd probably be worth avoiding the risk by creating
> > the event just once.
> >
> > I just wasn't immediately sure where to stash it. Probably just by adding a
> > field in StreamCtl, that ReceiveXlogStream() then sets? So far it's constant
> > once passed to ReceiveXlogStream(), but I don't really see a reason why it'd
> > need to stay that way?
>
> Oops, attached the patch this time.

Do we really want to create a new event every time? Those are kernel
objects, so they're not entirely free, but that part maybe doesn't
matter. Wouldn't it be cleaner to do it like we do in
pgwin32_waitforsinglesocket() which is create it once and store it in
a static variable? Or is that what you're suggesting above in the "I
wonder if" part?

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-01-17 14:09:11 Re: Support for NSS as a libpq TLS backend
Previous Message Simon Riggs 2022-01-17 13:44:02 Re: suboverflowed subtransactions concurrency performance optimize