Re: background triggers?

From: Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: background triggers?
Date: 2006-05-23 16:44:55
Message-ID: 1148402696.20217.22.camel@model.home.waw.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bob Pawley 2006-05-23 16:56:01 Re: Interface
Previous Message Tom Lane 2006-05-23 16:14:31 Re: Quering by Regular Expressions stored in table