Re: Append with naive multiplexing of FDWs

Fujita-san, thank you for taking time!

At Mon, 31 Aug 2020 19:10:39 +0900, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote in
> On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> > * I know your patch is a POC one, but one concern about it (and
> > Horiguchi-san's patch set) is concurrent data fetches by multiple
> > foreign scan nodes using the same connection in the case of
> > postgres_fdw. Here is an example causing an error:
>
> > select * from pt1, pt2 where pt2.a = 't22' or pt2.a = 't23';
> > ERROR: another command is already in progress
> > CONTEXT: remote SQL command: DECLARE c4 CURSOR FOR
> > SELECT a, b FROM public.t22 WHERE (((a = 't22'::text) OR (a = 't23'::text)))
>
> > (Horiguchi-san’s patch set doesn't work for this query either, causing
> > the same error. Though, it looks like he intended to handle cases
> > like this by a queuing system added to postgres_fdw to process such
> > concurrent data fetches.)
>
> I was wrong here; Horiguchi-san's patch set works well for this query.
> Maybe I did something wrong when testing his patch set. Sorry for
> that.

Yeah. postgresIterateForeignScan calls vacate_connection() to make the
underlying connection available if a server connection is busy with
another remote query. The mechanism is backed by a waiting queue
(add_async_waiter, move_to_next_waiter, remove_async_node).

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center