From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | git(at)jasonk(dot)me, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: FDW INSERT batching can change behavior |
Date: | 2024-08-09 19:55:00 |
Message-ID: | 93233153-6935-4063-af11-2371de896575@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 8/9/24 05:07, git(at)jasonk(dot)me wrote:
> Hi,
>
> ...
>
> The first insert does not use batching, so it goes R W R W R W R W R W (R for
> executing the default function to generate a slot: nodeModifyTable.c
> ExecModifyTable context.planSlot = ExecProcNode(subplanstate); W for inserting
> into the table). This way, whenever the default function is called, it returns
> a new value.
>
> The second insert uses batching, so it goes R R R W W W R R W W. The function
> returns the same value within a batch, and in this case, it causes a conflict:
>
> ERROR: duplicate key value violates unique constraint "gloc1_pkey"
> DETAIL: Key (a)=(5) already exists.
> CONTEXT: remote SQL command: INSERT INTO public.gloc1(a, b) VALUES ($1, DEFAULT), ($2, DEFAULT), ($3, DEFAULT)
>
> Tested on 15.2 and 16.4 I compiled myself.
>
Yeah, we don't seem to check for this. I don't recall if it didn't occur
to me we could have DEFAULT on the foreign table.
We could/should disable batching, but I'm not quite sure what exactly to
check. AFAIK this can happen only when there are default expressions on
the foreign table, so maybe that? Or maybe only when the DEFAULT calls a
volatile function?
Thanks for the report.
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2024-08-10 13:54:58 | Re: BUG #18559: Crash after detaching a partition concurrently from another session |
Previous Message | Aleš Zelený | 2024-08-09 16:18:44 | Re: BUG #18573: Analyze command consumes several GB of memory - more than analyzed table size |