Re: Asynchronous queries with bound data.

From: Вячеслав Блинников <slavmfm(at)gmail(dot)com>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Asynchronous queries with bound data.
Date: 2011-01-05 21:04:22
Message-ID: AANLkTinH33W+OdfKraM4OjStESefO1u5LipsR6u0nY0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

The whole thing is:
- server connect to the database and wait for incoming connections
- when incoming connection occurs, server request the database for some data
about connected client - server must do it asynchronously and without
creating any threads just for connected client (there can be more than
thousand clients)
- at moment of requesting data from the database there already can be some
active requests
- when database respond it is need to know for which client this data
received (and what kind of request it was)
That's all.

P.S. it is possible to implement it requesting data one-by-one (adding each
request to the queue and popping (FIFO) each request after each database'
respond) but it is slow because it's need to wait data transferring through
the net while database (server) itself will be idling.

[Did I figured out with some "cc"? Can I remove the commented previous
letters in each respond?]

5 января 2011 г. 23:10 пользователь Peter Geoghegan <
peter(dot)geoghegan86(at)gmail(dot)com> написал:

> 2011/1/5 Вячеслав Блинников <slavmfm(at)gmail(dot)com>:
> > Database connection using "libpq":
> > So, generally speaking, I need:
> > - send multiple queries using "PQsendQuery()" (or what else)
> > - bind some data (void*) to each qeury
> > - obtain results using "PQgetResult()" (or what else) and to know which
> data
> > is bound to each result (correspondence between queries and results)
> > How it can be implemented?
>
> You cannot "bind" data to a query. You cannot execute two queries in
> parallel with one connection. However, PGresults exist totally
> independently or the connection or thread that originated them, so
> feel free to stash them as you see fit.
>
> libpq usually operates within the same thread context as the client
> application, so in general it doesn't make sense to pass a function
> pointer (which you suggested in a slightly earlier mail to the list)
> that will be called back asynchronously like a signal handler.
> Asynchronous command processing just exists as a way to keep a GUI
> responsive and things like that, because PQExec() blocks.
>
> Maybe it would help if you stepped back and described your problem in
> broader terms.
>
> --
> Regards,
> Peter Geoghegan
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2011-01-05 21:12:26 Re: UUID column as pimrary key?
Previous Message Bill Moran 2011-01-05 20:43:01 Re: UUID column as pimrary key?