From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kieran McCusker <kieran(dot)mccusker(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15350: Getting invalid cache ID: 11 Errors |
Date: | 2018-09-13 04:22:31 |
Message-ID: | CAEepm=3NSOWRVWuD0RQiC-T3R8G=ma3O5YHs6sUSpk2MHKPjrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Sep 13, 2018 at 1:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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.
postgres=# select unaccent('hello');
WARNING: syscache access from _PG_init() is deprecated and will not
be allowed in a future release of PostgreSQL
unaccent
----------
hello
(1 row)
You see this warning only once per library per backend (including
parallel workers, as can be tested with the same trivial query with
force_parallel_mode = on, assuming 0002 is also applied so it doesn't
crash).
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
0001-hack-to-make-unaccent-crash-in-parallel-workers-v2.patch | application/octet-stream | 806 bytes |
0002-Defer-restoration-of-libraries-in-parallel-worker-v2.patch | application/octet-stream | 2.2 KB |
0003-Log-a-WARNING-if-_PG_init-accesses-syscache-v2.patch | application/octet-stream | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Mareks Kalnačs | 2018-09-13 10:03:49 | RE: PostgreSQL 10.0 SELECT LIMIT performance problem |
Previous Message | PG Bug reporting form | 2018-09-13 03:42:40 | BUG #15382: Error create dictionary in pg_dump |