Re: pg_sleep_enhancements.patch - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: pg_sleep_enhancements.patch
Date
Msg-id CAFj8pRBEryyMfkXg_e7Eg97yzCXSjPHxyhpnASwmY5wisixL1Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_sleep_enhancements.patch  (Vik Fearing <vik.fearing@dalibo.com>)
List pgsql-hackers



2014-01-29 Vik Fearing <vik.fearing@dalibo.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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Robert Haas
Date:
Subject: Re: Add force option to dropdb