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: | Whole Thread | Raw Message | 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
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 |