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
Date: Tue, 01 Jun 2021 17:41:40 -0400
Message-ID: <2855401.1622583700@sss.pgh.pa.us> (raw)
In-Reply-To: <17042-cfa218be6e24a03d@postgresql.org>
References: <17042-cfa218be6e24a03d@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, kim.brodowski@iserv.eu, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database
In-Reply-To: <2855401.1622583700@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox