2014-01-29 Vik Fearing
> On 01/29/2014 08:21 PM, Pavel Stehule wrote:
> > second question - is not this functionality too dangerous? If somebody
> > use it as scheduler, then
> >
> > a) can holds connect, session data, locks too long time
> > b) it can stop on query timeout probably much more ear
On 01/29/2014 08:21 PM, Pavel Stehule wrote:
> second question - is not this functionality too dangerous? If somebody
> use it as scheduler, then
>
> a) can holds connect, session data, locks too long time
> b) it can stop on query timeout probably much more early then user expect
>
> What is expec
2014-01-29 Vik Fearing
> On 01/29/2014 08:04 PM, Pavel Stehule wrote:
> > Hello
> >
> > I am looking on this patch
>
> Thank you for looking at it.
>
> > http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
> >
> > a) pg_sleep_for - no objection - it is simple and secure
>
> Okay.
>
>
On 01/29/2014 08:04 PM, Pavel Stehule wrote:
> Hello
>
> I am looking on this patch
Thank you for looking at it.
> http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
>
> a) pg_sleep_for - no objection - it is simple and secure
Okay.
> b) pg_sleep_until
>
> I am not sure - maybe th
Hello
I am looking on this patch
http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
a) pg_sleep_for - no objection - it is simple and secure
b) pg_sleep_until
I am not sure - maybe this implementation is too simply. I see two possible
risk where it should not work as users can ex
