Re: BUG #15350: Getting invalid cache ID: 11 Errors - Mailing list pgsql-bugs

From Kieran McCusker
Subject Re: BUG #15350: Getting invalid cache ID: 11 Errors
Date
Msg-id CAGgUQ6H0aHQ8WL4EF0U4pMCseMwwsHUOBuFOepsZGbZpCTJD1Q@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15350: Getting invalid cache ID: 11 Errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15350: Getting invalid cache ID: 11 Errors  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-bugs
Yes I'm using extensions - A bunch of them but I'm guessing it's likely ogr_fdw that will be causing the issue as I've only seen this on days when someone has imported data using ogr_fdw.


On Tue, 28 Aug 2018, 03:40 Tom Lane, <tgl@sss.pgh.pa.us> 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.

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.

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.

                        regards, tom lane

pgsql-bugs by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: BUG #15352: postgresql FDW error "ERROR: ORDER BY position 0 is not in select list"
Next
From: PG Bug reporting form
Date:
Subject: BUG #15357: Data goes to wrong partition in HASH Partitioned table