Re: BUG #15350: Getting invalid cache ID: 11 Errors
От | Thomas Munro |
---|---|
Тема | Re: BUG #15350: Getting invalid cache ID: 11 Errors |
Дата | |
Msg-id | CAEepm=2Mc_SmwQ46qF-eQuEVa_m_=t3sr+=hqw_Qiq7im5iPuw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15350: Getting invalid cache ID: 11 Errors (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #15350: Getting invalid cache ID: 11 Errors
|
Список | pgsql-bugs |
On Mon, Sep 3, 2018 at 5:05 AM Andres Freund <andres@anarazel.de> wrote: > On 2018-08-27 22:40:17 -0400, Tom Lane wrote: > > Thomas Munro <thomas.munro@enterprisedb.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... Any other views? It sounds like we do want a patch like the one I posted earlier. The question is whether we also want a new warning, and in later releases an error. Do we really want to crack down on extension libraries that wouldn't work in shared_preload_libraries? 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. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: