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

From rektide
Subject Re: NOTIFY/LISTEN on server, asynchronous processing
Date
Msg-id 20121211214759.GV23164@eldergods.com
Whole thread Raw
In response to Re: NOTIFY/LISTEN on server, asynchronous processing  (Sergey Konoplev <gray.ru@gmail.com>)
Responses Re: NOTIFY/LISTEN on server, asynchronous processing  (Sergey Konoplev <gray.ru@gmail.com>)
List pgsql-general
Hiya!

PgQ looks like cool technology, but it still violates the #1 thing I'm looking for, which is
a postgres-only solution. I don't see any reason why I'd want an external daemon ticking
the system over, and I'm hoping perhaps there's some way to coax Postgres itself into doing
this asychronous job processing, akin to the dblink technique mentioned twice today, but not
ugly.

NOTIFY/LISTEN again comes spiritually close, but is still restrained to only being a useful
construct for database clients; there's no resident processes that can react to database
events, and that's kind of a shame IMO.

-rektide

On Tue, Dec 11, 2012 at 12:58:21PM -0800, Sergey Konoplev wrote:
> Hi,
>
> On Tue, Dec 11, 2012 at 11:29 AM, rektide <rektide@voodoowarez.com> wrote:
> > 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.
>
> Use PgQ (http://wiki.postgresql.org/wiki/PGQ_Tutorial) for this
> purpose. It is simple to implement solution and it will allow you to
> preserve your queries between server restarts.
>
> --
> Sergey Konoplev
> Database and Software Architect
> http://www.linkedin.com/in/grayhemp
>
> Phones:
> USA +1 415 867 9984
> Russia, Moscow +7 901 903 0499
> Russia, Krasnodar +7 988 888 1979
>
> Skype: gray-hemp
> Jabber: gray.ru@gmail.com


pgsql-general by date:

Previous
From: David Boreham
Date:
Subject: Re: large database
Next
From: Mihai Popa
Date:
Subject: Re: large database