Re: libpq bad async behaviour
| От | Daurnimator |
|---|---|
| Тема | Re: libpq bad async behaviour |
| Дата | |
| Msg-id | CAEnbY+fSXe=EkPTqtZTK+9yzXAmnW4VRL8uyTOoibzpaw1b9Vw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: libpq bad async behaviour (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-hackers |
On 14 January 2015 at 08:40, Andres Freund <andres@2ndquadrant.com> wrote:
of porting work is just not going to be worth the cost. And it won't beI think that kind of solution isn't likely to be satisfying. The amount
easily hideable in the API at all as the callers will expect a normal
fd.
All that consumers of the API need is something they can `select()` or equivalent on.
> Yeah, this is a problem. Fixing it isn't easy, though, I think.
I think
extern PostgresPollingStatusType PQconnectPoll(PGconn *conn);
has the right interface. It returns what upper layers need to wait
for. I think we should extend pretty much that to more interfaces.
This would be a fine solution. That enum indeed has the correct values/semantics.
This
likely means that we'll need extended versions of PQFlush() and
PQconsumeInput() - afaics it shouldn't be much more?
PQping?
PQconnectPoll already has it.
Though, I think we could probably even reduce this down to a single common function for all cases:
PQpoll() or similar.
В списке pgsql-hackers по дате отправления: