ils/acl.h"
@@ -1383,9 +1384,21 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
ObjectAddressSet(address, ProcedureRelationId, funcOid);
+ /* Lock the function so nobody else can do anything with it. */
+ LockDatabaseObject(ProcedureRelationId, funcOid, 0, AccessExclusiveLock)
uot;
#include "tcop/pquery.h"
#include "tcop/utility.h"
#include "utils/acl.h"
@@ -1383,9 +1384,21 @@ AlterFunction(ParseState *pstate, AlterFunctionStmt *stmt)
ObjectAddressSet(address, ProcedureRelationId, funcOid);
+ /* Lock the function so nobody else can do anything w
On Fri, 4 Jul 2025 10:48:26 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote:
> >
> > On Tue, 1 Jul 2025 18:56:11 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > > CatalogIndexInsert is kinda "popular" function. It can b
Hi,
On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote:
>
> On Tue, 1 Jul 2025 18:56:11 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
>
> > CatalogIndexInsert is kinda "popular" function. It can be called in
> > different situations, not in all of which a violation of unique
> > constraint m
On Thu, 3 Jul 2025 23:18:12 +0900
Yugo Nagata wrote:
> On Tue, 1 Jul 2025 18:56:11 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
> > For example, with this patch such a query : "CREATE TYPE mood AS ENUM
> > ('happy', 'sad', 'happy');"
> > Will throw this error : "operation failed due to a
, ProcedureRelationId, funcOid);
+ /* Lock the function so nobody else can do anything with it. */
+ LockDatabaseObject(ProcedureRelationId, funcOid, 0, AccessExclusiveLock);
+
+ /*
+ * It is possible that by the time we acquire the lock on function,
+ * concurrent DDL has removed it. We can test this
Hi,
On Tue, Jul 1, 2025 at 5:47 PM Yugo Nagata wrote:
>
> On Mon, 30 Jun 2025 18:32:47 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
>
> > On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> > >
> > > I agree with Tom Lane that the behavior is expected, although it would be
> > > better
* existence of function. We get the tuple again to avoid the risk
+ * of function definition getting changed.
+ */
tup = SearchSysCacheCopy1(PROCOID, ObjectIdGetDatum(funcOid));
- if (!HeapTupleIsValid(tup)) /* should not happen */
- elog(ERROR, "cache lookup failed for function %u",
Hi,
On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
>
> On Fri, 27 Jun 2025 18:53:02 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
> > This patch fixes postgres behavior if I first create a function and
> > then try to CREATE OR REPLACE it in concurrent transactions.
> > But if the func
Copy1(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\&q
Hi,
On Thu, Jun 5, 2025 at 5:21 PM Yugo Nagata wrote:
>
> I've attached updated patches.
>
I have some comments on v4-0001 patch :
1)
heap_freetuple should be called for every tuple that we get from
SearchSysCacheCopy3.
But if tuple is valid after the first SearchSysCacheCopy3, we
overwrite the
ion. We get the tuple again to avoid the risk
+ * of function definition getting changed.
+ */
tup = SearchSysCacheCopy1(PROCOID, ObjectIdGetDatum(funcOid));
- if (!HeapTupleIsValid(tup)) /* should not happen */
- elog(ERROR, "cache lookup failed for function %u", funcOid);
+ if (!HeapT
Valid(tup))
+ ereport(ERROR,
+errcode(ERRCODE_UNDEFINED_OBJECT),
+errmsg("function \"%s\" does not exist",
+ NameListToString(stmt->func->objname)));
procForm = (Form_pg_proc) GETSTRUCT(tup);
--
2.43.0
>From 6c11eca73b0b5b847edf5e1eb5840ee692b1e5f
On Tue, 27 May 2025 09:00:01 +0300
Alexander Lakhin wrote:
> Hello Yugo,
>
> 31.03.2025 14:22, Yugo Nagata wrote:
> >> I found that multiple sessions concurrently execute CREATE OR REPLACE
> >> FUNCTION
> >> for a same function, the error "tuple concurrently updated" is raised.
> >> This is
>
On Tue, 27 May 2025 08:33:42 +0200
Jim Jones wrote:
> 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 behavio
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 R
Hello Yugo,
31.03.2025 14:22, Yugo Nagata wrote:
I found that multiple sessions concurrently execute CREATE OR REPLACE FUNCTION
for a same function, the error "tuple concurrently updated" is raised. This is
an internal error output by elog, also the message is not user-friendly.
I also found th
On Tue, 27 May 2025 10:03:58 +0800
jian he wrote:
> On Tue, May 27, 2025 at 1:35 AM Yugo Nagata wrote:
> >
> > > + /* Lock the function so nobody else can do anything with it. */
> > > + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0,
> > > AccessExclusiveLock);
> > > +
> > > + /*
> >
On Tue, May 27, 2025 at 1:35 AM Yugo Nagata wrote:
>
> > + /* Lock the function so nobody else can do anything with it. */
> > + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0,
> > AccessExclusiveLock);
> > +
> > + /*
> > + * It is possible that by the time we acquire the lock on functio
NameListToString(stmt->func->objname)));
procForm = (Form_pg_proc) GETSTRUCT(tup);
--
2.43.0
>From 094fd8d212e01634f74afcac8a9b8b0d26201813 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Mon, 31 Mar 2025 18:46:58 +0900
Subject: [PATCH v2 1/2] Prevent internal error at concurren
Hi,
On Thu, 22 May 2025 10:25:58 +0800
jian he wrote:
Thank you for looking into it.
> + /* Lock the function so nobody else can do anything with it. */
> + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0,
> AccessExclusiveLock);
> +
> + /*
> + * It is possible that by the time we acq
On Tue, 20 May 2025 17:30:35 +0200
Jim Jones wrote:
> I just briefly tested this patch and it seems to work as expected for
> CREATE OF REPLACE FUNCTION:
Thank you for reviewing the patch!
> I did the same for ALTER FUNCTION but I was unable to reproduce the
> error your reported. Could you pr
On Thu, May 22, 2025 at 10:25 AM jian he wrote:
>
hi.
earlier, i didn't check patch 0002.
i think in AlterFunction add
/* Lock the function so nobody else can do anything with it. */
LockDatabaseObject(ProcedureRelationId, funcOid, 0, AccessExclusiveLock);
right after
funcOid = LookupFun
On Mon, Mar 31, 2025 at 7:22 PM Yugo Nagata wrote:
>
> On Mon, 31 Mar 2025 20:00:57 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I found that multiple sessions concurrently execute CREATE OR REPLACE
> > FUNCTION
> > for a same function, the error "tuple concurrently updated" is raised. This
> >
Hi!
On 31.03.25 13:22, Yugo Nagata wrote:
> On Mon, 31 Mar 2025 20:00:57 +0900
> Yugo Nagata wrote:
>
>> Hi,
>>
>> I found that multiple sessions concurrently execute CREATE OR REPLACE
>> FUNCTION
>> for a same function, the error "tuple concurrently updated" is raised. This
>> is
>> an interna
00:00:00 2001
From: Yugo Nagata
Date: Mon, 31 Mar 2025 18:46:58 +0900
Subject: [PATCH] Prevent internal error at concurrent CREATE OR REPLACE
FUNCTION
---
src/backend/catalog/pg_proc.c | 40 ---
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/src/backend
; does not exist",
+ NameListToString(stmt->func->objname)));
+
procForm = (Form_pg_proc) GETSTRUCT(tup);
/* Permission check: must own function */
--
2.34.1
>From 49c890eb8cb115586e0e92294fb2fec60d80b8be Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Da
27 matches
Mail list logo
