From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: possible issue in postgres_fdw batching |
Date: | 2024-08-19 11:15:19 |
Message-ID: | fb8bc03c-03cb-4a8b-ab05-290f07e1e9e0@vondra.me |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/19/24 01:40, Tom Lane wrote:
> 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.)
>
Thanks, that's a great point. It didn't occur to me we're entitled to
just run the SELECT to completion, before proceeding to the INSERT. That
indeed means this function is fundamentally unsafe.
regards
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2024-08-19 11:39:27 | Re: gitmaster server problem? |
Previous Message | Nazir Bilal Yavuz | 2024-08-19 11:01:00 | Re: Use read streams in pg_visibility |