From: AgentM <agentm@themactionfaction.com>
To: pgsql general <pgsql-general@postgresql.org>
Subject: Re: Is there anyway to...
Date: Thu, 2 Nov 2006 14:55:50 -0500
Message-ID: <8ABD7C06-79D9-44F6-B21B-7C4F8E0FCB3B@themactionfaction.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0611021157280.1126-100000@denzel.in>
References: <Pine.LNX.4.33.0611021157280.1126-100000@denzel.in>
On Nov 2, 2006, at 15:00 , Richard Troy wrote:
>
>
> On Thu, 2 Nov 2006, AgentM wrote:
>>>
>>> Just some commentary... This is exactly the sort of thing cron is
>>> for. Duplicating that functionality in the RDBMS would be silly
>>> IMO. I don't see why you could consider cron to be "dirty" for
>>> this application...
>>
>> I actually tried to come up with something for this. There are plenty
>> of good reasons to have some timer functionality in the database:
>>
>> 1) it makes regular database-oriented tasks OS portable
>> 2) your cron user needs specific permissions + authorization to
>> access the database whereas postgres could handle "sudo"-like
>> behavior transparently
>> 3) there are triggers other than time that could be handy- on vacuum,
>> on db start, on db quit, on NOTIFY
>>
>> Unfortunately, the limitation I came across was for 2). There is no
>> way to use "set session authorization" or "set role" safely because
>> the wrapped code could always exit from the sandbox. So my timer only
>> works for db superusers.
>>
>> -M
>
> ...This type of need is exactly what custom written daemons are for.
> They're surely database and OS portable (or can be, at least),
> there's no
> need for any super-user capability of any kind, you can use any
> kind of
> trigger you like, and there's no permission leakage problem,
> either... I
> guess all you need is functioning nohup capability (which Windows
> systems
> may have trouble with, I don't know).
Sure- I wrote a custom daemon. But it has general usefulness. Instead
of ten clients listening on ten notifications (and holding open
connections for little reason), I would like to have one connection
handle all the notification events- based on which notification or
timer event, it could call a different stored procedure with
different roles. That way, I wouldn't need one connection open for
ever user that needs to listen and react. That simply doesn't scale.
Cheers,
M
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: agentm@themactionfaction.com, pgsql-general@postgresql.org
Subject: Re: Is there anyway to...
In-Reply-To: <8ABD7C06-79D9-44F6-B21B-7C4F8E0FCB3B@themactionfaction.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox