Horton

Re: logical replication launcher crash on buildfarm

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>
Date: 2017-04-16T05:35:46Z
Lists: pgsql-hackers 
On Sat, Apr 15, 2017 at 12:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maybe we need to rethink the division of labor between parallel.c
> and execParallel.c, but that would depend on somebody explaining
> what the difference is in the first place.

parallel.c handles general concerns related to any sort of
parallelism, particularly those related to transaction management,
hence it's in src/backend/access/transam. execParallel.c handles
concerns that are specific to the executor, hence it's in
src/backend/executor.  The header comment for execParallel.c is fairly
informative on this point; now that I look at it, parallel.c has only
a stub comment, which really ought to be expanded.  Note that while
parallel *query* uses both, a parallel utility command will likely use
only the facilities in parallel.c, so the distinction is not academic.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Avoid passing function pointers across process boundaries.

  2. Don't use bgw_main even to specify in-core bgworker entrypoints.