Re: pg_collation_actual_version() ERROR: cache lookup failed for collation 123

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_collation_actual_version() ERROR: cache lookup failed for collation 123
Date: 2021-02-17 07:04:01
Message-ID: YCy/4WpJEDLY/PN1@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 17, 2021 at 03:08:36PM +1300, Thomas Munro wrote:
> tp = SearchSysCache1(COLLOID, ObjectIdGetDatum(oid));
> if (!HeapTupleIsValid(tp))
> + {
> + if (found)
> + {
> + *found = false;
> + return NULL;
> + }
> elog(ERROR, "cache lookup failed for collation %u", oid);
> + }
> collform = (Form_pg_collation) GETSTRUCT(tp);
> version = get_collation_actual_version(collform->collprovider,
> NameStr(collform->collcollate));
> + if (found)
> + *found = true;
> }

FWIW, we usually prefer using NULL instead of an error for the result
of a system function if an object cannot be found because it allows
users to not get failures in a middle of a full table scan if things
like an InvalidOid is mixed in the data set. For example, we do that
in the partition functions, for objectaddress functions, etc. That
would make this patch set simpler, switching
get_collation_version_for_oid() to just use a missing_ok argument.
And that would be more consistent with the other syscache lookup
functions we have here and there in the tree.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-02-17 07:16:25 Re: New Table Access Methods for Multi and Single Inserts
Previous Message Michael Paquier 2021-02-17 06:36:20 Re: progress reporting for partitioned REINDEX