|
You will have a trigger that, once new tuples are created (or older update and so on) issues a NOTIFY. Somewhere (within PostgreSQL or outside it) there will be a process that issued a LISTEN and is locked until a notify comes in. Then it does process whatever you need to do. As an example your trigger function will be something like and your listening process will be something like Thanks for the examples. I’ll look into them. This makes your processing fully asynchronous, and with some tune allows you to decide the start/stop/resume policy as you need/wish. Besides, it is quite hard for me to get to the point where you need to check for new data every second, and therefore why you are not satisfied with pg_cron or stuff like that. pg_cron doesn’t start the task instantly and queues subsequent runs, if the task is still running. I just need to start the task once and it should keep running until stopped / killed. Maybe I'll have to rephrase it. Suppose I have a procedure and want to start it without the client where I start the procedure waiting for it to finish. And I want the procedure to continue even if the client that
started it quits. And I want to be able to check if the procedure is still running. Dirk
|
