Re: cache lookup failed for collation 0

From: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cache lookup failed for collation 0
Date: 2019-04-12 06:13:36
Message-ID: CAM2+6=V+9TXyJi+WDqwqxacirL6e91FqFWMx+XyOionfAYbD0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 11, 2019 at 10:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> writes:
> > Do you mean, the code in get_collation_isdeterministic() should look like
> > something like below?
>
> > If colloid = InvalidOid then
> > return TRUE
> > ELSE IF tuple is valid then
> > return collisdeterministic from the tuple
> > ELSE
> > return FALSE
>
> I think it's appropriate to fail if we don't find a tuple, for any
> collation oid other than zero. Again, if you trace through the
> behavior of the longstanding collation check functions like
> lc_ctype_is_c(), you'll see that that's what happens (except for
> some hardwired OIDs that they have fast paths for).
>

OK.

Attached patch which treats "collation 0" as deterministic in
get_collation_isdeterministic() and returns true, keeping rest of the code
as is.

> regards, tom lane
>

--
Jeevan Chalke
Technical Architect, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Attachment Content-Type Size
fix_cache_lookup_error_collation_v2.patch text/x-patch 2.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-04-12 06:44:18 Re: REINDEX CONCURRENTLY 2.0
Previous Message Michael Paquier 2019-04-12 04:44:03 Re: setLastTid() and currtid()