From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: logical replication launcher crash on buildfarm |
Date: | 2017-03-28 01:31:02 |
Message-ID: | 52d78669-0523-4e60-a263-841c96210256@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27/03/17 19:01, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund <andres(at)anarazel(dot)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.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-03-28 01:36:20 | Re: Potential data loss of 2PC files |
Previous Message | Andres Freund | 2017-03-28 01:25:46 | Re: logical decoding of two-phase transactions |