Re: Race condition in WaitForBackgroundWorkerStartup

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Jeremy Finzel <finzelj(at)gmail(dot)com>, amit(dot)kapila16(at)gmail(dot)com
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Race condition in WaitForBackgroundWorkerStartup
Date: 2018-11-13 18:18:54
Message-ID: 16a13e0172d667d3aede1037ec8dfa9d1548782f.camel@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2018-11-13 at 07:57 -0600, Jeremy Finzel wrote:
> ...
>
> I'm unclear on what counts as "worker initialization". The error is
> happening in the worker_spi_main function, not in the
> worker_spi_launch function. So does an immediate error in
> worker_spi_main count as part of the worker initialization?
>

I don't think it does (or should). worker_spi_main is pretty much the
worker body, and worker initialization pretty much means just "we've
initialized the worker process (including tracking it in shmem etc.)
and invoked it's main function".

I'd also argue the behavior is expected to depend on the machine to
some extent - depending on speed and load the machine may hit the error
before/after the GetBackgroundWorkerPid call, producing different
results.

So I'd say the behavior seems correct, at least from this POV.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-13 18:21:29 Re: Sync ECPG scanner with core
Previous Message Andres Freund 2018-11-13 18:07:05 Re: Refactoring the checkpointer's fsync request queue