NOTIFY/LISTEN on server, asynchronous processing - Mailing list pgsql-general

From rektide
Subject NOTIFY/LISTEN on server, asynchronous processing
Date
Msg-id 20121211192938.GU23164@eldergods.com
Whole thread Raw
Responses Re: NOTIFY/LISTEN on server, asynchronous processing  (Kiriakos Georgiou <kg.postgresql@olympiakos.com>)
Re: NOTIFY/LISTEN on server, asynchronous processing  (Sergey Konoplev <gray.ru@gmail.com>)
Re: NOTIFY/LISTEN on server, asynchronous processing  (Sim Zacks <sim@compulab.co.il>)
List pgsql-general
Hi all, I'm writing seeking help for making asynchronous & decoupled processes run on a
Postgres server.

Here's my current hairbraned workingis:
1. Create an table "async_process" and attach a trigger after.
2. Establish a dblink to localhost.
3. dblink_send_query("update async_process set counter = counter + 1;") from other sprocs
3. Designated processing hanging off this "async_process" table now runs.

All I'm doing is using a table, to create a trigger, that can be run asynchronously.

There's at least two things gross about this strategy:
1. A "async_process" table exists only because I need a trigger that can be updated at will.
2. Having to dblink to oneself to run a query from inside the database asynchronously.

Postgres has a capability for doing async work: NOTIFY/LISTEN. I'd like to verify first,
LISTEN is only for clients, correct? There's no way I can define something resident on
postgres itself that will LISTEN, that can be targetted by notifications?

Does anyone have suggestions for decoupling work done on a server, for breaking up a task
into multiple asychronous pieces? I believe I've described 1. a viable if ugly means of
doing so, and 2. limitations in the primary asynchronous toolsuite of Postgres, and am
looking for ways to make more progress.

Regards,
-rektide


pgsql-general by date:

Previous
From: Alex Burkoff
Date:
Subject: Re: execution plan is wrong, or the query ?
Next
From: Kiriakos Georgiou
Date:
Subject: Re: NOTIFY/LISTEN on server, asynchronous processing