Re: possible issue in postgres_fdw batching

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: possible issue in postgres_fdw batching
Date: 2024-08-18 23:40:59
Message-ID: 1229236.1724024459@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> Consider this simplified example:

> CREATE TABLE t (a INT);
> CREATE FOREIGN TABLE f (a INT) SERVER loopback
> OPTIONS (table_name 't');
> CREATE FUNCTION counter() RETURNS int LANGUAGE sql AS
> $$ SELECT COUNT(*) FROM f $$;

> And now do

> INSERT INTO f SELECT counter() FROM generate_series(1,100);

> With batch_size=1 this produces a nice sequence, with batching we start
> to get duplicate values - which is not surprising, as the function is
> oblivious to the data still in the buffer.

> The first question is if this is a bug.

I'd say no; this query is unduly chummy with implementation details.
Even with no foreign table in the picture at all, we would be fully
within our rights to execute the SELECT to completion before any
of the insertions became visible. (Arguably, it's the current
behavior that is surprising, not that one.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-08-18 23:44:39 Re: Cirrus CI for macOS branches 16 and 15 broken
Previous Message Tomas Vondra 2024-08-18 23:26:58 possible issue in postgres_fdw batching