On Tue, Mar 6, 2012 at 3:31 PM, Andrew Dunstan <and...@dunslane.net> wrote:> > We don't slavishly need to reproduce every piece of cron. In any case, on my > Linux machine at least, batch is part of the "at" package, not the "cron" > package. If you want anything at all done, then I'd suggest starting with a > simple scheduler. Just about he quickest way to get something rejected in > Postgres is to start with something overly complex and baroque.
I sort agree with this, I think. However, I don't see the need to have Postgres get involved with scheduling and triggering of jobs at all. Rather, it just doesn't have support for what I'd think of as a "job", period, regardless of how it gets triggered. The crux of the issue for me is that sometimes it's pretty annoying to have to maintain a socket connection just to get some things to run for a while: I can't tell the database "execute stored procedure (not UDF) 'job' in a new backend, I'm going to disconnect now". Nearly relatedly, I've heard from at least two people in immediate memory that would like database sessions to be reified somehow from their socket, so that they could resume work in a session that had a connection blip. At the same time, it would really suck to have an "idle in transaction" because a client died and didn't bother to reconnect and clean up...a caveat. Nevertheless, I think session support (think "GNU screen" or "tmux") is both useful and painful to accomplish without backend support (for example, the BackendKey might be useful). And stored procedures are a familiar quantity at large... Thoughts? -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
