Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Fri, Jul 15, 2016 at 3:20 AM, Tom Lane wrote: > Andreas Seltenreich writes: >> Tom Lane writes: >>> We've dealt with similar issues in places like pg_relation_size() by >>> making the functions return NULL instead of throwing an error for an >>>

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

Andreas Seltenreich writes: > Tom Lane writes: >> We've dealt with similar issues in places like pg_relation_size() by >> making the functions return NULL instead of throwing an error for an >> unmatched argument OID. > Note that Michael Paquier sent a patch implementing this

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

Tom Lane writes: > Dilip Kumar writes: >> So I think changing the view definition and calling this function on >> indexrelid will remove the error. So I think >> correct fix is to change view definition, as I proposed in above patch. [...] > We've dealt with similar issues

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

Dilip Kumar writes: > On Thu, Jul 14, 2016 at 1:37 PM, Amit Langote > wrote: >> Can we say that pg_get_indexdef() has "side-effects" because it can error >> like this? Shouldn't such a function be marked *volatile*? Because if I >> do so by

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Thu, Jul 14, 2016 at 5:29 PM, Dilip Kumar wrote: > > On Thu, Jul 14, 2016 at 1:40 PM, Michael Paquier > wrote: >> >> -pg_get_indexdef(I.oid) AS indexdef >> +pg_get_indexdef(X.indexrelid) AS indexdef >> Fixing it this way looks

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Thu, Jul 14, 2016 at 1:40 PM, Michael Paquier wrote: > -pg_get_indexdef(I.oid) AS indexdef > +pg_get_indexdef(X.indexrelid) AS indexdef > Fixing it this way looks like a good idea to me to bypass those cache > lookup errors caused by non-index

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Thu, Jul 14, 2016 at 1:37 PM, Amit Langote wrote: > Can we say that pg_get_indexdef() has "side-effects" because it can error > like this? Shouldn't such a function be marked *volatile*? Because if I > do so by updating pg_proc, the plan changes (perhaps) to

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On 2016/07/14 17:07, Amit Langote wrote: > Can we say that pg_get_indexdef() has "side-effects" because it can error > like this? Shouldn't such a function be marked *volatile*? Because if I > do so by updating pg_proc, the plan changes (perhaps) to a safe one in > this context: Didn't mean to

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Thu, Jul 14, 2016 at 4:59 PM, Dilip Kumar wrote: > I was wrong, Actually If we change the view and call function on > x.indexrelid, It will fix the issue, because pg_get_indexdef(x.indexrelid) > is non equal clause and of course will not fall in same equivalence class.

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On 2016/07/14 16:08, Dilip Kumar wrote: > Query: > postgres=# select * from pg_catalog.pg_indexes where indexdef is not null; > ERROR: cache lookup failed for index 2619 > > If we see the plan for the same: > --- > Nested Loop Left Join >Join Filter:

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

On Thu, Jul 14, 2016 at 12:38 PM, Dilip Kumar wrote: > I am not sure what should be the correct fix for this problem. > > I think even if we try to call this function on index oid > *pg_get_indexdef(*x.indexrelid*) *AS indexdef, problem will not be > solved, because both