Re: libpq read/write

Tom, you seem to know everything related to Postgres, so thanks for your
time and answers. I'm blown away by your dedication and knowledge.

Regarding PQisBusy, and similar, even for "non-blocking" behaviour, you are
essentially expecting the user to have their own event loop, and only
invoke the relevant libpq functions when I/O is actually possible, right?

e.g. in many cases, you'd set the socket to be non-blocking, and then just
return to the user "I want to read more data".

What's actually stopping the implementation calling read/write directly? In
the blocking case, that's correct behaviour. In the non-blocking case, I
don't see how it's helpful to use epoll, because you should just return to
the user right away.

Thanks
Samuel

On Sun, 31 Mar 2019 at 03:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Samuel Williams <space(dot)ship(dot)traveller(at)gmail(dot)com> writes:
> > I've been doing some profiling and I was surprised to see that libpq uses
> > epoll when handling what essentially amounts to blocking reads/writes.
>
> Yup.
>
> > I was just wondering why it needed to be so complicated?
>
> So that we can also support nonblocking behavior (cf PQisBusy).
>
> If the library were being written from scratch today, I doubt anybody
> would bother with that; it'd make more sense for an application to
> use a separate thread for the database interaction, if there were
> other things it needed to pay attention to concurrently. But it is
> what it is.
>
> regards, tom lane
>