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:
I think that kind of solution isn't likely to be satisfying. The amount
of porting work is just not going to be worth the cost. And it won't be
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ereport bug
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE and RLS