Re: logical replication launcher crash on buildfarm
От | Petr Jelinek |
---|---|
Тема | Re: logical replication launcher crash on buildfarm |
Дата | |
Msg-id | 8941c9b1-f6e9-1056-39f2-7bc7336c4d00@2ndquadrant.com обсуждение исходный текст |
Ответ на | [HACKERS] logical replication launcher crash on buildfarm (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: logical replication launcher crash on buildfarm
|
Список | pgsql-hackers |
On 28/03/17 03:31, Petr Jelinek wrote: > On 27/03/17 19:01, 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. 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. >> > > It affects parallel workers same way, I'll write patch for HEAD soon, > 9.6 probably with some delay. I'll expand the InternalBgWorkers thing > that was added with logical replication to handle this in similar > fashion how we do fmgrtab. > Btw now that I look at the code, I guess we'll want to get rid of bgw_main completely in HEAD given that we can't guarantee it will be valid even for shared_preload_library libraries. For older branches I would leave things as they are in this regard as there don't seem to be any immediate issue for standard binaries. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: