cache lookup failed error for partition key with custom opclass
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37144psql -h localhost -U postgresBuilt from patchset v3 (message #3), August 18, 2026 at 05:03 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37144_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37144_3 && git checkout t37144_3Patchset v3 (message #3) is on t37144_3
Hi,
Consider the following test:
CREATE OR REPLACE FUNCTION dummy_binaryint4(a int4, b int4) RETURNS int4 AS
$$ BEGIN RETURN a; END; $$ LANGUAGE 'plpgsql' IMMUTABLE;
CREATE OPERATOR CLASS custom_opclass2 FOR TYPE int2 USING BTREE AS OPERATOR
1 = , FUNCTION 1 dummy_binaryint4(int4, int4);
t=# CREATE TABLE list_tab(a int2, b int) PARTITION BY LIST (a
custom_opclass2);
*ERROR: cache lookup failed for function 0*
In the above test creating OP class type int2, but passing the function of
int4
type. During CREATE PARTITION, ComputePartitionAttrs() able to resolve the
opclass
for the partition key (partition key type is int2), but while looking for a
method for the int2 -
it unable to find the proper function and end up with the cache lookup
failed error.
Error coming from RelationBuildPartitionKey().
I think overall this is expected but still error can be better - like all
the other
places where get_opfamily_proc() unable to find valid function oid.
PFA patch, where added elog() to add the error message same as all other
places.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
Attachments:
cache_lookup_fail.patchtext/x-patch; charset=US-ASCII; name=cache_lookup_fail.patchDownload+4-0
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
PFA patch, where added elog() to add the error message same as all other
places.
Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standards.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
PFA patch, where added elog() to add the error message same as all other
places.Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standards.
Thanks Tom.
I go thorough the get_opfamily_proc() in the system and added the
check for InvalidOid.
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standards.
I go thorough the get_opfamily_proc() in the system and added the
check for InvalidOid.
Think I did that already, please compare your results with
278cb4341103e967189997985b09981a73e23a34
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 25, 2017 at 7:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standards.I go thorough the get_opfamily_proc() in the system and added the
check for InvalidOid.Think I did that already, please compare your results with
278cb4341103e967189997985b09981a73e23a34
Thanks Tom.
regards, tom lane
--
Rushabh Lathia