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
>>> unmatched argument OID.
>
>> Note that Michael P
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 in another
> thread:
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 in places like pg_relat
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 updating pg_proc, the plan changes (perhaps) to a safe
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 like a good idea to me to bypass those cache
>> loo
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 relations. Now I think that you ne
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 a safe one in
> this context:
>
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 w
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.
-pg_get_indexdef
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: (t
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 will fall in same equival
While running sqlsmith tool, I saw some cache lookup failure issues
reported,
While investigating those issues, I found one strange reason, and I feel
It's a bug in pg code.
Query:
postgres=# select * from pg_catalog.pg_indexes where indexdef is not null;
ERROR: cache lookup failed for index 261
12 matches
Mail list logo
