From: | Doug McNaught <doug(at)mcnaught(dot)org> |
---|---|
To: | Johan Vromans <jvromans(at)squirrel(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Last modification time |
Date: | 2006-02-12 13:57:41 |
Message-ID: | 877j80ptm2.fsf@asmodeus.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Johan Vromans <jvromans(at)squirrel(dot)nl> writes:
> Doug McNaught <doug(at)mcnaught(dot)org> writes:
>> Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
>> think of that before.
>
> LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
> subscriber that something happened. But in my case, the report
> generating program runs only occasionally and will not be permanently
> running subscribed. I'm not sure how to use LISTEN/NOTIFY for that.
Well you need something trigger-based, because I don't think it would
be useful to look at modification dates on the database files or
anything like that (checkpoints, vacuum, rolled back transactions etc
would change those even when the user-visible data didn't change).
You could have the trigger update a single-row table and have the
report generator (or a wrapper) poll for it, or you could have it send
a NOTIFY to a little program sitting on a connection, which would then
kick off the report generator.
-Doug
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2006-02-12 14:21:43 | Re: Last modification time |
Previous Message | Michael Glaesemann | 2006-02-12 12:09:35 | Re: Each foo must have a bar |