On Fri Jan 12, 2024 at 11:13 AM CST, Tristan Partin wrote:
> On Fri Jan 12, 2024 at 10:45 AM CST, Robert Haas wrote:
> > On Mon, Jan 8, 2024 at 1:03 AM Tristan Partin <tristan@neon.tech> wrote:
> > > I think the way to go is to expose some variation of libpq's
> > > pqSocketPoll(), which I would be happy to put together a patch for.
> > > Making frontends, psql in this case, have to reimplement the polling
> > > logic doesn't strike me as fruitful, which is essentially what I have
> > > done.
> >
> > I encourage further exploration of this line of attack. I fear that if
> > I were to commit something like what you've posted up until now,
> > people would complain that that code was too ugly to live, and I'd
> > have a hard time telling them that they're wrong.
>
> Completely agree. Let me look into this. Perhaps I can get something up
> next week or the week after.
Not next week, but here is a respin. I've exposed pqSocketPoll as
PQsocketPoll and am just using that. You can see the diff is so much
smaller, which is great!
In order to fight the race condition, I am just using a 1 second timeout
instead of trying to integrate pselect or ppoll. We could add
a PQsocketPPoll() to support those use cases, but I am not sure how
available pselect and ppoll are. I guess on Windows we don't have
pselect. I don't think using the pipe trick that Heikki mentioned
earlier is suitable to expose via an API in libpq, but someone else
might have a different opinion.
Maybe this is good enough until someone complains? Most people would
probably just chalk any latency between keypress and cancellation as
network latency and not a hardcoded 1 second.
Thanks for your feedback Robert!
--
Tristan Partin
Neon (https://neon.tech)