Re: Is there anyway to... - Mailing list pgsql-general
From | louis gonzales |
---|---|
Subject | Re: Is there anyway to... |
Date | |
Msg-id | 454A4B0A.4030904@linuxlouis.net Whole thread Raw |
In response to | Re: Is there anyway to... (AgentM <agentm@themactionfaction.com>) |
List | pgsql-general |
Apparently this isn't the first time someone else thought a sleep or timer mechanism, independent of user action would be of great value and didn't want to use external programs to accomplish it. http://developer.*postgresql*.org/pgdocs/postgres/release-8-2.html * Add a server-side *sleep* *function* pg_sleep() (Joachim Wieland): SELECT pg_sleep(1); AgentM wrote: > > On Nov 2, 2006, at 14:02 , Glen Parker wrote: > >> louis gonzales wrote: >> >>> Hey Brian, >>> Yeah I had considered this, using cron, I just feel like that is >>> too dirty. >>> Actually I didn't see Andreas' post, can someone forward that? >>> I'm running this application on Solaris 9. Ultimately what I want >>> to know is, is there something that is internal to postgresql that >>> can be used that doesn't need external action, to make it do some >>> task? >>> Some built in function that can be set to do some simple task on a >>> daily - or other time - interval, where all of the defined users >>> may not have any activity with the database for day's or week's at >>> a time, but this builtin function still operates? >>> Am I making any sense with how I'm asking this? I could of course >>> have cron do a scheduled task of checking/incrementing/ decrementing >>> and define triggers to occur when one of the cron delivered actions >>> sets the appropriate trigger off, but are there other methods that >>> are standard in the industry or are we stuck with this type of >>> external influence? >> >> >> >> 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Email: louis.gonzales@linuxlouis.net WebSite: http://www.linuxlouis.net "Open the pod bay doors HAL!" -2001: A Space Odyssey "Good morning starshine, the Earth says hello." -Willy Wonka
pgsql-general by date: