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-13 18:31:54
Message-ID: 900ad3fe-151e-4876-a399-fa12faa2c653@vondra.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

I took a closer look at this, planning to way to fix this, but I think
it's actually a bit worse than reported - both in impact and ways how to
fix that.

The problem is it's not really specific to DEFAULT values. The exact
same issue exists whenever the insert uses the expressions directly.
That is, if you do this:

insert into grem1 (a) values (counter()), (counter()),
(counter()), (counter()),
(counter());

it will misbehave in exactly the same way as with the default values. Of
course, this also means that my original idea to disable batching if the
foreign table has (volatile) expression in the DEFAULT value won't fly.

This can happen whenever the to-be-inserted rows have any expressions.
But those expressions are evaluated *outside* ModifyTable - in the nodes
that produce the rows. In the above example it's ValueScan. But it could
be any other node. For example:

insert into grem1 (a) select counter() from generate_series(1,5);

does that in a subquery. But AFAICS it could be any other node.

Ideally we'd simply set batch_size=1 for those cases, but at this point
I have no idea how to check this from ModifyTable :-(

In retrospect the issue is pretty obvious, yet I haven't thought about
this while working on the batching. This is embarrassing.

regards

--
Tomas Vondra

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2024-08-13 18:32:01 Re: BUG #18582: fixed range of search for empty slot in SLRU
Previous Message Tom Lane 2024-08-13 18:23:25 Re: BUG #18581: psql symbol append_history not found when quitting