Lists: | pgsql-hackers |
---|
From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Subject: | pg_sleep_enhancements.patch |
Date: | 2014-01-29 19:04:07 |
Message-ID: | CAFj8pRABP5EkzV1L099M6ujJTVo0k6_0RufXZ2p_Lnpt_Vm7Ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hello
I am looking on this patch
http://www.postgresql.org/message-id/525FE206.6000502@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 expect
a) what will be expected behave whem time is changed - CET/CEST ?
b) what will be expected behave when board clock is not accurate and it is
periodically fixed (by NTP) - isn't better to sleep only few seconds and
recalculate sleeping interval?
Regards
Pavel
From: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Subject: | Re: pg_sleep_enhancements.patch |
Date: | 2014-01-29 19:14:46 |
Message-ID: | 52E95326.9050403@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.6000502@dalibo.com
>
> a) pg_sleep_for - no objection - it is simple and secure
Okay.
> 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 expect
>
> a) what will be expected behave whem time is changed - CET/CEST ?
There is no risk there, the wake up time is specified with time zone.
> b) what will be expected behave when board clock is not accurate and
> it is periodically fixed (by NTP) - isn't better to sleep only few
> seconds and recalculate sleeping interval?
We could do that, but it seems like overkill. It would mean writing a
new C function whereas this is just a simple helper for the existing
pg_sleep() function. So my vote is to keep the patch as-is.
--
Vik
From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Subject: | Re: pg_sleep_enhancements.patch |
Date: | 2014-01-29 19:21:46 |
Message-ID: | CAFj8pRDh0mnmPsiHaY5SEZmz=SihH+WZDdKkR_SS0fPD+mgq-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2014-01-29 Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
> 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.6000502@dalibo.com
> >
> > a) pg_sleep_for - no objection - it is simple and secure
>
> Okay.
>
> > 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 expect
> >
> > a) what will be expected behave whem time is changed - CET/CEST ?
>
> There is no risk there, the wake up time is specified with time zone.
>
> > b) what will be expected behave when board clock is not accurate and
> > it is periodically fixed (by NTP) - isn't better to sleep only few
> > seconds and recalculate sleeping interval?
>
> We could do that, but it seems like overkill. It would mean writing a
> new C function whereas this is just a simple helper for the existing
> pg_sleep() function. So my vote is to keep the patch as-is.
>
>
Ok
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 expected use case?
Regards
Pavel
> --
> Vik
>
>
From: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Subject: | Re: pg_sleep_enhancements.patch |
Date: | 2014-01-29 19:30:48 |
Message-ID: | 52E956E8.30706@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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 expected use case?
It is no more dangerous than plain pg_sleep(). The use case is
convenience and clarity of code.
I don't think people will be using it as a scheduler any more than they
do with pg_sleep() because it can't cross transaction boundaries.
--
Vik
From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Subject: | Re: pg_sleep_enhancements.patch |
Date: | 2014-01-29 19:38:06 |
Message-ID: | CAFj8pRBEryyMfkXg_e7Eg97yzCXSjPHxyhpnASwmY5wisixL1Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2014-01-29 Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
> 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 expected use case?
>
> It is no more dangerous than plain pg_sleep(). The use case is
> convenience and clarity of code.
>
> I don't think people will be using it as a scheduler any more than they
> do with pg_sleep() because it can't cross transaction boundaries.
>
I am sure so experienced user didn't use it. But beginners can be messed
due similarity with schedulers.
I invite a) documented these risks b) opinion of other hackers
Probably when it is used as single statement in transaction, then it can
breaks only vacuum
Pavel
>
> --
> Vik
>
>