From: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Peter Eisentraut <peter_e@gmx.net>
Subject: Re: logical replication launcher crash on buildfarm
Date: Sat, 15 Apr 2017 00:01:54 -0400
Message-ID: <5615.1492228914@sss.pgh.pa.us> (raw)
In-Reply-To: <548f9c1d-eafa-e3fa-9da8-f0cc2f654e60@2ndquadrant.com>
References: <e3c35f3a-426d-b1ca-7fe5-9241c2717013@2ndquadrant.com>
<CA+Tgmoae_obbYapxDhELe852TO1nFGOdVbWiUwa6Gf+ODxjHnQ@mail.gmail.com>
<0471e978-b121-ad2f-2879-f1694d9a5ce7@2ndquadrant.com>
<d217ee26-f3d1-4079-0110-3f7ee44ad6b4@2ndquadrant.com>
<2124fb62-2393-8525-4fe9-b95b1b689d09@2ndquadrant.com>
<CA+TgmobNi6++NFCQgSay4A05-FNVFfYVKxfBa00zke8vqU1V3Q@mail.gmail.com>
<09d8ad33-4287-a09b-a77f-77f8761adb5e@2ndquadrant.com>
<CA+TgmoZktru0SK1b9888gYF=zmX_haRm+6i8rBP0APS6yO8+NA@mail.gmail.com>
<8ebd3aa3-55eb-1106-7c10-7e7579f94582@2ndquadrant.com>
<CA+TgmobGk3DEo++oqkFi8AaYXhCs-0DUNMU9HdCh56udXFF=PA@mail.gmail.com>
<20170401021928.47zjjryhty5kdzqz@alap3.anarazel.de>
<548f9c1d-eafa-e3fa-9da8-f0cc2f654e60@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
> So this is what I came up with on plane. Generalized the loading
> functionality into load_library_function which that can load either
> known postgres functions or call load_external_function.
I've had more than enough of seeing buildfarm failures from culicidae,
so I whacked this around until I was happy with it and pushed it.
Further adjustments welcome of course.
> I am not quite sure if fmgr.c is best place to put it, but I didn't want
> to include stuff from executor in bgworker.c.
I really did not care for putting those references into fmgr.c. Aside
from the layering violations involved, there was a type cheat, in that
you had functions with entirely different signatures in the same list.
I eventually decided that the least ugly solution was to create two
different pointer arrays and frontend functions, one for bgworkers and
one for parallel workers. That ends up requiring only one extra
export/import, to make ParallelQueryMain accessible in parallel.c.
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.
> As with previous patch, 9.6 will need quite different patch as we need
> to keep compatibility there,
I don't really understand why 9.6 needs a significantly different
patch. AFAICS, it simply does not work (with any reliability)
for a loadable module to call CreateParallelContext directly in 9.6.
The only thing that actually works is to call the undocumented
CreateParallelContextForExternalFunction. I suggest that we could
back-patch this as-is, if we add CreateParallelContextForExternalFunction
as a trivial wrapper around CreateParallelContext.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, petr.jelinek@2ndquadrant.com, andres@anarazel.de, robertmhaas@gmail.com, peter_e@gmx.net
Subject: Re: logical replication launcher crash on buildfarm
In-Reply-To: <5615.1492228914@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox