From: | Stefan Huehner <stefan(at)huehner(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | 9.6beta2: query failure with 'cache lookup failed for type 0' |
Date: | 2016-07-02 13:10:56 |
Message-ID: | 20160702131056.GD3165@huehner.biz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
re-testing our application Openbravo on 9.6beta2 i found the following query failing to run with
ERROR: cache lookup failed for type 0
Tested on 9.6beta2
Specifically debian package version '9.6~beta2-1.pgdg+1' from apt.postgresql.org
SELECT
SUM(C_ORDERLINE.LINENETAMT),
C_CURRENCY_SYMBOL2 (SUM(C_ORDERLINE.LINENETAMT))
FROM C_ORDER, C_ORDERLINE
WHERE C_ORDER.C_ORDER_ID = C_ORDERLINE.C_ORDER_ID
GROUP BY C_ORDER.DOCUMENTNO
ORDER BY C_ORDER.DOCUMENTNO;
Note: query is slimmed down manually which still reproduces the issue (cut down from biggger query), which explain the kind of (now)(now) useless pl-function.
To reproduce in new empty database:
CREATE OR REPLACE FUNCTION public.c_currency_symbol2(p_amount numeric)
RETURNS character varying AS
$BODY$ DECLARE
BEGIN
RETURN p_amount;
END ; $BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
create table c_order (c_order_id varchar(32) primary key, documentno varchar(60));
create table c_orderline (c_orderline_id varchar(32) primary key, c_order_id varchar(32), linenetamt numeric, c_currency_id varchar(32));
Deleting any more out of the query seems to no longer trigger the problem.
Also changing the 'c_orderline' create table statement to not have the last column 'c_currency_id' (which is not even referenced in the query) also makes the issue no longer reproducible.
Regards,
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-07-02 14:31:32 | Docs, backups, and MS VSS |
Previous Message | Dirk Rudolph | 2016-07-02 12:23:35 | Leaking memory in text_overlay function |