On Tue, Mar 6, 2012 at 3:31 PM, Andrew Dunstan <andrew@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