On Thu, Sep 13, 2018 at 4:22 PM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Sep 13, 2018 at 1:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > > ... Do we really want to crack down on
> > > extension libraries that wouldn't work in shared_preload_libraries?
> >
> > That is, perhaps, a fair question; but I see little benefit to users
> > in such a library design. Most people who are using a library heavily
> > would likely wish to have it preloaded.
> >
> > > What about hypothetical libraries that are smart enough to avoid
> > > making such calls when they detect that they're running from
> > > shared_preload_libraries -- you'd generate false warnings when loaded
> > > the regular way.
> >
> > I find that argument too thin to take seriously. If the library
> > can manage that, it might as well just postpone the calls all the
> > time, rather than have two different operating modes that would
> > require separate testing. What would be the advantage of the
> > extra complication?
>
> Ok, 0003 (attached) is a straw-man patch to log a warning. I guess it
> won't be too popular with anyone who has worked on making syscache as
> fast as possible.
I would like to close this case, so unless anyone objects, tomorrow
I'm going to push the reordering patch (0002 in my earlier email) so
that we stop getting bug reports about extensions that crash in
parallel workers (even though we consider those extensions to be
operating out of contract). If someone wants to do a patch that will
display warnings when extensions break that rule (something like the
0003 patch I sketched), that can be done separately.
--
Thomas Munro
http://www.enterprisedb.com