Re: possible issue in postgres_fdw batching - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: possible issue in postgres_fdw batching
Date
Msg-id fb8bc03c-03cb-4a8b-ab05-290f07e1e9e0@vondra.me
Whole thread Raw
In response to Re: possible issue in postgres_fdw batching  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 8/19/24 01:40, Tom Lane wrote:
> Tomas Vondra <tomas@vondra.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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [PROPOSAL] : Disallow use of empty column name in (column_name '') in ALTER or CREATE of foreign table.
Next
From: Joe Conway
Date:
Subject: Re: gitmaster server problem?