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 |
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() |