Re: BUG #15350: Getting invalid cache ID: 11 Errors

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

In response to

Responses

Browse pgsql-bugs by date

  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