Re: FDW INSERT batching can change behavior

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

In response to

Responses

Browse pgsql-bugs by date

  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