Hi all,

On a Debian Buster/64 Bit I run Postgres 11 (apt-cache info):

Package: postgresql-11
Version: 11.7-0+deb10u1
Maintainer: Debian PostgreSQL Maintainers <team+postgre...@tracker.debian.org>

I tried to update the running server by executing the following SQL update 
script using psql:

---8<-----------------------------------------------
BEGIN;
-- add a column to an existing table
-- add a new table
-- add several db functions
-- replace a DB function:
DROP FUNCTION public.get_result2(mytaskid bigint, OUT data bytea, OUT metadata 
jsonb, OUT errortext text, OUT vanished boolean);
CREATE FUNCTION public.get_result2(mytaskid bigint, OUT data bytea, OUT 
metadata jsonb, OUT errortext text, OUT vanished boolean) RETURNS record
[…]
COMMIT;
---8<-----------------------------------------------

About ~350 clients were connected to the server when I ran the above script, a 
few of them using, inter alia, the function get_result2() which ought to be 
replaced.

Immediately after running the script, the log was filled with errors

---8<-----------------------------------------------
ERROR:  cache lookup failed for function 1821571
CONTEXT:  PL/pgSQL function get_result2(bigint) while casting return value to 
function's return type
STATEMENT:  SELECT data, metadata, errortext, vanished FROM 
get_result2(26671107)
---8<-----------------------------------------------

Interestingly, some clients were reporting errors while trying to call a 
/different/ DB function which had not been touched by the above script.

According to some older reports I found searching the internet for the error, 
the pg_catalog was probably damaged.  As a restart of the daemon didn't help, 
and following the recommendations in the older reports, I dumped the data (no 
idea if it was damaged, too, though) and re-installed the cluster form scratch. 
 It now again works as expected using the modified schema.

I would agree that updating the schema of a database server under considerable 
load is not the best idea, but it should *never* damage the database itself (it 
would be acceptable if the transaction just fails, though).

Any idea what happened here, i.e. what caused the error, and how I can avoid it?

Thanks in advance,
Albrecht.

Attachment: pgprqhppn7Wqa.pgp
Description: PGP signature

Reply via email to