On Fri, 4 Jul 2025 14:58:05 +0900
Yugo Nagata wrote:
> 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>
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
On Tue, 1 Jul 2025 18:56:11 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> 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:
> >
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
On Mon, 30 Jun 2025 18:32:47 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> 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 fu
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
On Fri, 27 Jun 2025 18:53:02 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> 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 :
Thank you for your comments!
> 1)
> heap_freetuple should be calle
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
On Thu, 5 Jun 2025 16:26:08 +0900
Yugo Nagata wrote:
> On Tue, 3 Jun 2025 17:39:50 +0900
> Yugo Nagata wrote:
>
> > On Tue, 27 May 2025 09:00:01 +0300
> > Alexander Lakhin wrote:
>
> > I know there are other scenarios where the same is raises and I agree that
> > it would be better to conside
On Tue, 3 Jun 2025 17:39:50 +0900
Yugo Nagata wrote:
> On Tue, 27 May 2025 09:00:01 +0300
> Alexander Lakhin wrote:
> I know there are other scenarios where the same is raises and I agree that
> it would be better to consider a more global solution instead of addressing
> each of them. However,
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
On Fri, 23 May 2025 10:37:42 +0800
jian he wrote:
> 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
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
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 internal error output by elog, also the message is not user-friendl
25 matches
Mail list logo