Re: BUG #15350: Getting invalid cache ID: 11 Errors
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kieran McCusker <kieran.mccusker@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-09-13T01:42:00Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Defer restoration of libraries in parallel workers.
- de4fe83c7e6d 9.6.11 landed
- 98a4e814e473 10.6 landed
- 9d178fb92804 11.0 landed
- 6c3c9d418918 12.0 landed