Re: logical replication launcher crash on buildfarm
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: 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-27T17:05:24Z
Lists: pgsql-hackers
On 2017-03-27 13:01:11 -0400, Robert Haas wrote: > On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund <andres@anarazel.de> wrote: > > Robert, Petr, either of you planning to fix this (as outlined elsewhere > > in the thred)? > > Oh, I didn't realize anybody was looking to me to fix this. Well, it's borked in 9.6. I'm starting to get annoyed by culicidae's failures ;) > I sort of thought that it was fallout from the logical replication > patch and that Petr or Peter would deal with it. If that's not the > case, I'm not totally unwilling to take a whack at it, but I don't > have much personal enthusiasm for trying to figure out how to make > dynamic loading on the postgres binary itself work everywhere, so if > it falls to me to fix, it's likely to get a hard-coded check for some > hard-coded name. I'm all for that approach - there seems very little upside in the dynamic loading approach. Just defining a bgw_entry_points[enum BuiltinBGWorkerType] -> bgworker_main_type array seems to be simple enough - it's not like we're going to add new types of builtin bgworkers at runtime. - Andres
Commits
-
Avoid passing function pointers across process boundaries.
- 9c225acf0b97 9.6.3 landed
- 32470825d36d 10.0 landed
-
Don't use bgw_main even to specify in-core bgworker entrypoints.
- 0ef26bb394ab 9.5.7 landed
- 9b6e8d8f86ac 9.6.3 landed
- 2113ac4cbb12 10.0 landed