Re: CustomScan support on readfuncs.c - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: CustomScan support on readfuncs.c
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F80116DCC3@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: CustomScan support on readfuncs.c  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: CustomScan support on readfuncs.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > Are you suggesting to pass the object name on software build time?
> 
> Yes.  That's what test_shm_mq and worker_spi already do:
> 
>         sprintf(worker.bgw_library_name, "test_shm_mq");
>
OK, I ripped out the portion around dfmgr.c.

> > If so, it may load incorrect libraries when DBA renamed its filename.
> > At least, PostgreSQL cannot prevent DBA to rename library filenames
> > even if they try to deploy "pg_strom.so", "pg_strom.20151106.so" and
> > "pg_strom.20151030_bug.so" on same directory.
> 
> I agree.  But that's not a new problem that needs to be solved by this
> patch.  It already exists - see above.
>
It still may be a potential problem, even though a corner case.
I'll try to implement an internal API to know "what is my name".

The attached main patch (custom-scan-on-readfuncs.v3.patch) once
removes TextOutCustomScan, thus all the serialized tokens become
known to the core backend, and add _readCustomScan() at readfuncs.c.
It deserializes CustomScan nodes from cstring tokens, especially,
reloads the pointer of CustomScanMethods tables using a pair of
library name and symbol name.
Thus, it also requires custom scan providers to keep the methods
table visible from external objects.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Uh-oh: documentation PDF output no longer builds in HEAD
Next
From: Craig Ringer
Date:
Subject: Re: Multixid hindsight design