From: Tom Lane <tgl@sss.pgh.pa.us>
To: kim.brodowski@iserv.eu
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can
 Corrupt Database
In-reply-to: <17042-cfa218be6e24a03d@postgresql.org>
References: <17042-cfa218be6e24a03d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 01 Jun 2021 20:45:06 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2855400.1622583700.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 01 Jun 2021 17:41:40 -0400
Message-ID: <2855401.1622583700@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2855401.1622583700%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> My co-worker Martin von Wittich came up with a set of minimal SQL statements
> to trigger the issue:

> bug.sql:

>   DROP TYPE foo CASCADE;
>   CREATE TYPE foo AS (foo INTEGER);
  
>   CREATE OR REPLACE FUNCTION foobar() RETURNS foo AS $$
>   BEGIN
>     RETURN ROW(1)::foo;
>   END
>   $$
>   LANGUAGE plpgsql;
  
>   SELECT foobar();

> In order to trigger the issue, we need to run our statements in parallel:
>   psql -f test.sql & psql -f test.sql

This doesn't seem terribly surprising.  Occasionally one session's
foobar() will run at an instant where type foo doesn't exist, thanks
to the other session's script having dropped the type and not yet
recreated it.  The "cache lookup failed" messages are a bit scary,
but they arise in situations where the type did exist a moment ago
but now it's gone.

There's been occasional proposals to prevent this sort of thing by
obtaining a lock on every type name mentioned in a function and
holding it till (probably) end of transaction.  The cost of that,
compared to the value, has dissuaded us from doing it.

			regards, tom lane