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+postgresql@xxxxxxxxxxxxxxxxxx> 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:
pgprFF_moC9mD.pgp
Description: PGP signature
