Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread David Steele 
On 12/23/16 7:26 PM, Tom Lane wrote:
> David Steele  writes:
>> What about a ./configure option that basically removes the min/max
>> limits of every setting where it makes sense?
> 
> It's pretty much never the case that anything goes; for example,
> are we going to insist that the code be able to respond sanely to
> negative checkpoint_timeout?  The GUC limit mechanism was really
> invented to avoid having to do that, as much or more than preventing
> users from picking "bad" values.

Well, this option would only be available if you built Postgres from
source which I doubt most users are doing.  I had originally thought it
would be best to enforce some sanity on the values, but then thought it
might be useful to give settings completely bogus values for testing
purposes.

I'd be OK with some sensible limits, but I think that defeats to point
to some extent.

> And I don't want to maintain two sets of limits, so I'm not for
> some sort of "training wheels off" vs "training wheels on" GUC.

I wasn't proposing that this be a GUC.  If I gave that impression it's
because I didn't convey my idea accurately.

> We could move towards a project policy that limits be set according
> to what's sensible for the code to support rather than what seems
> like useful ranges.  Again though, most of the ensuing work needs to
> be documentation not code changes.

I'm honestly not sure I would want to kick off all the training wheels.
For instance, a poorly considered checkpoint_timeout setting may lead to
terrible performance, but should still leave the user with a consistent
database, and hopefully some wisdom in the bargain.

-- 
-David
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread Tom Lane 
David Steele  writes:
> What about a ./configure option that basically removes the min/max
> limits of every setting where it makes sense?

It's pretty much never the case that anything goes; for example,
are we going to insist that the code be able to respond sanely to
negative checkpoint_timeout?  The GUC limit mechanism was really
invented to avoid having to do that, as much or more than preventing
users from picking "bad" values.

And I don't want to maintain two sets of limits, so I'm not for
some sort of "training wheels off" vs "training wheels on" GUC.

We could move towards a project policy that limits be set according
to what's sensible for the code to support rather than what seems
like useful ranges.  Again though, most of the ensuing work needs to
be documentation not code changes.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread David Steele 
On 12/23/16 6:12 PM, Michael Paquier wrote:
> On Sat, Dec 24, 2016 at 6:02 AM, David Steele  wrote:
>> On 12/23/16 10:24 AM, Tom Lane wrote:
>>> Andres Freund  writes:
 While it's not a particularly good idea to set it to 1s on a production
 system, I don't see why we need to prevent that. It's not like 30s is
 likely to be a good idea either.
>>>
 Hence I'd like to set the lower limit to 1s.
>>>
>>> OK, but the documentation for it needs some work if you're going to
>>> do that.  It only warns against making the timeout too large, not
>>> too small.
>>
>> +1 for the lower limit and the docs.
> 
> I wish we were more loose regarding the limits of some parameters, see
> for example this recent thread about bgwriter ones:
> https://www.postgresql.org/message-id/f6e58a22-030b-eb8a-5457-f62fb08d7...@bluetreble.com
> So +1 for lowering checkpoint_timeout, lower values are stupid for
> production systems, but not for developers.

What about a ./configure option that basically removes the min/max
limits of every setting where it makes sense?  We can discuss what's
good for the user without being inconvenienced ourselves.

It's something I'd be willing to write a patch for if there's interest.
We can start with a few that have been discussed and work our way out
from there.

I agree with Andres about lowering the checkpoint_timeout limit in
general, but it seems like this would allow us to make development more
convenient even when we can't agree on changing limits for production
builds.

-- 
-David
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread Michael Paquier 
On Sat, Dec 24, 2016 at 6:02 AM, David Steele  wrote:
> On 12/23/16 10:24 AM, Tom Lane wrote:
>> Andres Freund  writes:
>>> While it's not a particularly good idea to set it to 1s on a production
>>> system, I don't see why we need to prevent that. It's not like 30s is
>>> likely to be a good idea either.
>>
>>> Hence I'd like to set the lower limit to 1s.
>>
>> OK, but the documentation for it needs some work if you're going to
>> do that.  It only warns against making the timeout too large, not
>> too small.
>
> +1 for the lower limit and the docs.

I wish we were more loose regarding the limits of some parameters, see
for example this recent thread about bgwriter ones:
https://www.postgresql.org/message-id/f6e58a22-030b-eb8a-5457-f62fb08d7...@bluetreble.com
So +1 for lowering checkpoint_timeout, lower values are stupid for
production systems, but not for developers.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread David Steele 
On 12/23/16 10:24 AM, Tom Lane wrote:
> Andres Freund  writes:
>> While it's not a particularly good idea to set it to 1s on a production
>> system, I don't see why we need to prevent that. It's not like 30s is
>> likely to be a good idea either.
> 
>> Hence I'd like to set the lower limit to 1s.
> 
> OK, but the documentation for it needs some work if you're going to
> do that.  It only warns against making the timeout too large, not
> too small.

+1 for the lower limit and the docs.

-- 
-David
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread Tom Lane 
Andres Freund  writes:
> While it's not a particularly good idea to set it to 1s on a production
> system, I don't see why we need to prevent that. It's not like 30s is
> likely to be a good idea either.

> Hence I'd like to set the lower limit to 1s.

OK, but the documentation for it needs some work if you're going to
do that.  It only warns against making the timeout too large, not
too small.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

2016-12-23 Thread Fabien COELHO 


Hello Andres,


for testing - like yesterday's 6ef2eba3f - it's annoying that
checkpoint_timeout has 30s minimum. I've now locally patched that to be
1s a significant number of times.

While it's not a particularly good idea to set it to 1s on a production
system, I don't see why we need to prevent that. It's not like 30s is
likely to be a good idea either.

Hence I'd like to set the lower limit to 1s.


My 0.02€:

I have also resorted to reduce this limit in order to reduce latency and 
avoid postgres freezing on checkpoints, before checkpoint buffers where 
sorted. I think I may have tried down to 0.1s which involved some changes, 
and it worked quite well for the purpose.


So basically I would also be in favor to reduce the lower limit down to 1 
second, maybe with a warning output when set to low values, say under 1 
minute, as you propose.


--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers