From: | Alexander Farber <alexander(dot)farber(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: async queries in Perl and poll()/select() loop - how to make them work together? |
Date: | 2010-11-01 16:58:55 |
Message-ID: | AANLkTinaLD5cHz6REDe7pnTTA4UWOcsGNJnrnjEXzg+T@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello Andy and others,
On Mon, Nov 1, 2010 at 3:33 PM, Andy Colson <andy(at)squeakycode(dot)net> wrote:
> On 11/1/2010 4:29 AM, Alexander Farber wrote:
>> I have a small multiplayer game, a non-forking daemon
>> reading/writing to sockets and running in a IO::Poll loop.
>>
>> I.e. I would like to "fire and forget" queries.
>>
>> But unfortunately I get the error:
>> DBD::Pg::st execute failed: Cannot execute
>> until previous async query has finished
>> even though I'm not using PG_OLDQUERY_WAIT
> I believe one database connection can have one async query going at a time.
why are there 3 contants
http://search.cpan.org/dist/DBD-Pg/Pg.pm#Asynchronous_Constants
then? They suggest you can fire a query and forget
> I dont see anyplace in the docs that connect (or connect_cached) supports
> PG_ASYNC.
True, I've removed it (the problem still persists).
> Each iteration of your loop is blowing away the previous values, which
> should cause problems. I assume this is just test code? Is your real code
> really going to connection 10 times per person? You wont be able to support
> very many concurrent users that way. The code above might work if you
> switched it arrays (@dbh and @sth).
No I just need one connection, because I have
1 process (without any forked processes or threads),
which loops in a poll() loop.
> Async queries gives you the ability to fire one query, let the db work on it
> while you do something else, and them come back to it. You need to think
> about your layout (cuz I'm betting your example code does not reflect what
> you really want to do).
>
> Even with async querys, you eventually have to call $dbh->pg_result, so its
> not going to be fire and forget. To really do fire and forget, and totally
> take the stats processing away from game play processing, I'd suggest an
> event queue (or rpc), like zeromq, PGQ or gearman.
Thanks I'll look at it or maybe I'll fork 1 more process,
and open a pipe to it (then I can poll() it too).
Regards
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos Mennens | 2010-11-01 17:06:42 | Re: 8.4 Data Not Compatible with 9.0.1 Upgrade? |
Previous Message | Richard Broersma | 2010-11-01 16:52:36 | Re: 8.4 Data Not Compatible with 9.0.1 Upgrade? |