From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, 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-02 17:05:42 |
Message-ID: | 20180902170542.ojz6btqto7b4zix6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2018-08-27 22:40:17 -0400, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > We could probably improve that situation by making syscache lookups
> > (and probably other things too) fail when called from _PG_init() in
> > regular backends so that extension authors are made aware of this
> > hazard, or perhaps go the other way and change the order we do things
> > in parallel workers.
>
> Hmm. There's an argument to be made for the latter: we don't really
> want stuff failing in parallel workers if it works fine normally.
Yea, I guess there's an argument to be made for that.
> On the other hand, it seems clear to me that we *don't* want extensions to
> be doing stuff like syscache lookups in _PG_init(), because that would
> prevent them from working as shared_preload_libraries entries.
Yea, that doesn't seem great.
> And on the third hand, intentionally breaking code that used to work
> isn't likely to win us many friends either. So I'm not sure that your
> first option is really tenable. Perhaps we could get away with doing
> it in HEAD and not back-patching ... but that does little for existing
> problems.
I wonder if we could make it warn in all branches and error out hard in
master? That way hopefully most extensions would be fixed long before
the next release comes out, and people don't load new libraries at that
crazy a rate...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-02 17:35:27 | Re: Two constraints with the same name not always allowed |
Previous Message | Alvaro Herrera | 2018-09-02 17:05:11 | Re: Two constraints with the same name not always allowed |