On Tue, 2006-05-23 at 15:56 +0000, Chris Browne wrote: > > The use that I have for this at the moment, and I can think of many > > other uses, is that I want to populate a statistics table each time > > that a table is updated. But the code to populate the table takes 10 > > seconds to run. I don't want the user to have to wait 10 seconds to > > add a record. > > This seems a case for using NOTIFY/LISTEN. > > - You have a process connected to the database that runs LISTEN, > causing it to listen for a particular message. > > LISTEN regen_statistics; > > - Your trigger submits a notification: > > NOTIFY regen_statistics; Some time ago I fell into quite similair problem. But LISTEN/NOTIFY was not a solution. In that case I needed to *disconnect* and never bother about the outcome of a long running background trigger. So if I may re-phrase the question: "is there a way to have a trigger, that, when launched, can check if it's already running in backgroung for some other INSERT, return imediately if so, but turn into background for a long-lasting job if not". The functionality required is "lazy" update of agregate tables, which need not be 100% acurate, but should be kept in-sync whenever possible. -R
