Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION
Date
Msg-id cc705ec7-20b1-46f5-b49d-7a5542b3ac34@uni-muenster.de
Whole thread Raw
In response to Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION
List pgsql-hackers
Hi Yugo

On 26.05.25 18:39, Yugo Nagata wrote:
> I can see the error when two concurrent transactions issue
> "alter function f() immutable".


I might have missed something in my last tests... I could now reproduce
the behaviour you mentioned.

I've tested v2 and it works as described. CREATE OR REPLACE FUNCTION and
ALTER TABLE no longer raise an error after the lock by the concurrent
transaction was freed.

One quick question in v2-002:

     tup = SearchSysCacheCopy1(PROCOID, ObjectIdGetDatum(funcOid));
-    if (!HeapTupleIsValid(tup)) /* should not happen */
-        elog(ERROR, "cache lookup failed for function %u", funcOid);
+    if (!HeapTupleIsValid(tup))
+        ereport(ERROR,
+                errcode(ERRCODE_UNDEFINED_OBJECT),
+                errmsg("function \"%s\" does not exist",
+                       NameListToString(stmt->func->objname)));


Is it really ok to change this error message here? Did the addition of
LockDatabaseObject change the semantics of the previous message? Other
similar parts of the code still report "cache lookup failed for function
x". I don't have a strong opinion here, but perhaps we should keep these
messages consistent at least throughout the file?

Thanks!

Best, Jim




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Michael Paquier
Date:
Subject: Re: Add pg_get_injection_points() for information of injection points