Re: [HACKERS] Make versus effective stack limit in regression tests
On 06.11.2010 00:39, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 11/05/2010 05:45 PM, Tom Lane wrote: Anyway, what this points up is that we are making a very conservative assumption about what to do when getrlimit() returns RLIM_INFINITY. It does not seem real reasonable to interpret that as 100kB on any modern platform. I'm inclined to interpret it as 4MB, which is the same default stack limit that we use on Windows. +1. After looking a bit closer, I think the real problem is that get_stack_depth_rlimit's API fails to distinguish between unknown and unlimited. In the first case we ought to have a conservative default, whereas in the second case not. It's already the case that (a) max_stack_depth is a SUSET parameter, and (b) for either unknown or unlimited RLIMIT_STACK, we will let a superuser set whatever value he wants, and it's on his head whether that value is safe or not. That part of the behavior seems OK. What's not OK is using the same built-in default value in both cases. We need to fix it so that InitializeGUCOptions can tell the difference. If it can, I think the current default of 2MB is OK --- most people will be fine with that, and those who aren't can select some other value. Yeah, I bumped into this two years ago but it didn't lead to a patch: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00918.php +1 on choosing 2MB for RLIM_INFINITY. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Make versus effective stack limit in regression tests
On 11/05/2010 05:45 PM, Tom Lane wrote: Anyway, what this points up is that we are making a very conservative assumption about what to do when getrlimit() returns RLIM_INFINITY. It does not seem real reasonable to interpret that as 100kB on any modern platform. I'm inclined to interpret it as 4MB, which is the same default stack limit that we use on Windows. +1. cheers andrew -- 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] Make versus effective stack limit in regression tests
Andrew Dunstan and...@dunslane.net writes: On 11/05/2010 05:45 PM, Tom Lane wrote: Anyway, what this points up is that we are making a very conservative assumption about what to do when getrlimit() returns RLIM_INFINITY. It does not seem real reasonable to interpret that as 100kB on any modern platform. I'm inclined to interpret it as 4MB, which is the same default stack limit that we use on Windows. +1. After looking a bit closer, I think the real problem is that get_stack_depth_rlimit's API fails to distinguish between unknown and unlimited. In the first case we ought to have a conservative default, whereas in the second case not. It's already the case that (a) max_stack_depth is a SUSET parameter, and (b) for either unknown or unlimited RLIMIT_STACK, we will let a superuser set whatever value he wants, and it's on his head whether that value is safe or not. That part of the behavior seems OK. What's not OK is using the same built-in default value in both cases. We need to fix it so that InitializeGUCOptions can tell the difference. If it can, I think the current default of 2MB is OK --- most people will be fine with that, and those who aren't can select some other value. 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
