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
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 |