MIME-Version: 1.0
References: <CAFCRh-9R91Huzk2KFS8iKEo_eSXaZ0iAkGwx6LxfUexKzkeeRA@mail.gmail.com>
 <CAFCRh--frt-aqnMo2F619FK6sU=3RJkxFRoQ8P8i5mdieQtpOQ@mail.gmail.com>
In-Reply-To: <CAFCRh--frt-aqnMo2F619FK6sU=3RJkxFRoQ8P8i5mdieQtpOQ@mail.gmail.com>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Tue, 27 Aug 2024 15:20:22 +0200
Message-ID: <CAFCRh-9byhoFk-orgjn9iL6HOq9q5SLH7=nzgSvqdyom6ZOGyw@mail.gmail.com>
Subject: Re: Using PQsocketPoll() for PIPELINE mode
To: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFCRh-9byhoFk-orgjn9iL6HOq9q5SLH7%3DnzgSvqdyom6ZOGyw%40mail.gmail.com>
Precedence: bulk

On Tue, Aug 27, 2024 at 12:23=E2=80=AFPM Dominique Devienne <ddevienne@gmai=
l.com> wrote:
> On Wed, Aug 14, 2024 at 2:50=E2=80=AFPM Dominique Devienne <ddevienne@gma=
il.com> wrote:
> > Hi. I've now used successfully the new PQsocketPoll() API
> > in the context of waiting for notifications, using beta2 and 3.
> >
> > But now I'm looking into using it in the context of PIPELINE mode.
> > Where I suppose both forRead and forWrite are 1, but the return
> > code only indicates whether the condition is met. The doc says nothing
> > about OR or AND semantic, when both forRead and forWrite are true.
> >
> > Perhaps it's deemed obvious from the use of select() or poll()?
> > Or is one supposed to call it once with forRead=3DforWrite=3D1 and
> > a timeout, then call it again twice with just one forFlag set and
> > a 0 timeout, to know the "details" about which "side" is ready?
> >
> > Or hasn't this use case been considered for PQsocketPoll(),
> > and thus the current return code isn't has precise as it could be?
> >
> > Thanks for any precisions, --DD
>
> Hi. No answers. Was it wrong timing (vacations) or
> is something wrong with my questions? Thanks, --DD

Looking at https://doxygen.postgresql.org/libpq__pipeline_8c_source.html,
it does indeed seem like `select()` can inform about ready forRead and forW=
rite
independently, and thus that the current signature of PQsocketPoll()
is not ideal
to be used in the context of pipeline mode, which would be a pity, for
a new API.

I get that the original thinking about PQsocketPoll() was neither for
notifications,
not for pipeline mode, but shouldn't it be? That same example should ideall=
y be
writable in terms of PQsocketPoll(), using a few syscalls, no?

Once again, this is late, although my original questions are now 2 weeks ol=
d.
After all, PQsocketPoll() has not been released yet officially. Thanks, --D=
D

```
fd_set input_mask;
fd_set output_mask;
int sock =3D PQsocket(conn); [...]
if (select(sock + 1, &input_mask, &output_mask, NULL, NULL) < 0) { error }
// Process any results, so we keep the server's output buffer free
// flowing and it can continue to process input
if (FD_ISSET(sock, &input_mask)) {
    PQconsumeInput(conn); [...]
}
// Write more rows and/or the end pipeline message, if needed
if (FD_ISSET(sock, &output_mask)) {
    PQflush(conn); [...]
}
```