Horton

Re: logical replication launcher crash on buildfarm

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Petr Jelinek <petr@2ndquadrant.com>, Peter Eisentraut <peter_e@gmx.net>
Date: 2017-03-28T02:51:53Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> I wasn't thinking of introducing bgw_builtin_id.  My idea was just
> along the lines of

> if (bgw_library_name == NULL && bgw_function_name != NULL)
> {
>     if (strcmp(bgw_function_name, "ParallelQueryMain") == 0)
>        ParallelQueryMain(blah);
>     else if (strcmp(bgw_function_name, "LogicalReplicationMain") == 0)
>        LogicalReplicationMain(blah);
> }

> I think something like that is certainly better for the back-branches,
> because it doesn't cause an ABI break.  But I think it would also be
> fine for master.

That seems perfectly reasonable from here: surely the cost of a couple
of strcmp's is trivial in comparison to a process launch.

We can redesign the API whenever this way starts getting unwieldy,
but that's likely to be quite some time away.

			regards, tom lane

Commits

  1. Avoid passing function pointers across process boundaries.

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