Skip site navigation (1) Skip section navigation (2)

Re: Asynchronous Communication across two independent components

From: Damien Dougan <damien(dot)dougan(at)mobilecohesion(dot)com>
To: Darko Prenosil <darko(dot)prenosil(at)finteh(dot)hr>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Asynchronous Communication across two independent components
Date: 2003-03-25 09:15:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces

Thanks for the response, but I'm not sure if your suggestions will meet my 
needs - as the page you referenced seems to suggest that these operations 
must all go over the same connection (and I have a Sender and a Receiver on 
separate connections).

Some comments embedded below ...

On Monday 24 March 2003 9:27 pm, you wrote:

> You can send whole bunch of SQL commands using PQsendQuery, not only one !
> After that you can get more than one PGResults depending on what commands
> you send to Postgres. You only need to terminate it with ";".
> For example:
> WHERE id = 1; COMMIT;");
> When PQSendQuery command is executed, queries are just send to server.
> Non-blocking means: program will not block and wait for results to come !!!
> After that you should use combination of PQconsumeInput, PQisBusy and
> PQgetResult. You can even cancel rest of the queries with PQrequestCancel.
> It is all explained at:
> , and it
> works perfectly (spiking from my experience) !!!

I did have a read through this before posting - and I was hoping the above 
mechanisms would do the trick for me - but there appears to be two problems 
with the PQsendQuery and PQgetResult.

(1) You cannot call PQsendQuery on the same connection until PQgetResult has 
returned null.

(2) You cannot call PQgetResult on a different connection from PQsendQuery to 
obtain the results of a query.

So whilst your solution would be fine for asynchronous comms within a single 
connection, I'm afraid its not what I'm looking for!

> If You need to wait to see if first command passes, and then send another,
> threads and non-blocking commands can't help You! Then You simple must
> execute with PQExec and wait for result !
> > I also looked at the LISTEN/NOTIFY, which seemed promising. However,
> > there does not appear to be any mechanism to identify the event that
> > caused the notification. I was hoping to be able to have the Receiver
> > handle the notification by going to the appropriate relation and picking
> > up the data which was now ready for it - but there's no way to know which
> > entry it is!
> You can RAISE NOTICE inside of the function("stored procedure") with
> custom text. But You do not need this. PQsendQuery with multiple sql
> commands is what you need !

Thanks for the RAISE NOTICE heads-up - I'll take a look at this.


In response to


pgsql-interfaces by date

Next:From: Damien DouganDate: 2003-03-25 12:23:46
Subject: Re: Asynchronous Communication across two independent components
Previous:From: Darko PrenosilDate: 2003-03-24 21:27:01
Subject: Re: Asynchronous Communication across two independent components

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group