Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

I wrote: > So, agreed, let's commit some temporary debug code and see what the > buildfarm can teach us. Will go work on that in a bit. After reviewing the buildfarm results, I'm feeling nervous about this whole idea again. For the most part, the unaccounted-for daylight between the maximum

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > Fwiw here's the pmap info from burbot (Linux Sparc64): > 136 48 48 rw---[ stack ] > 136 48 48 rw---[ stack ] > 136 48 48 rw---[ stack ] > 136 48 48 rw---[ stack ] > 136 56 56 rw---[ stack ] >

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Fri, Jul 8, 2016 at 3:32 PM, Tom Lane wrote: > Hm, after reading the man page I don't quite see how that would help? > You'd have to already know the mapped stack address range in order to > call the function without getting ENOMEM. I had assumed unmapped pages would just

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > Searching for info on ia64 turned up this interesting thread: > https://www.postgresql.org/message-id/21563.1289064886%40sss.pgh.pa.us Yeah, that's the same one I referenced upthread ;-) > From that discussion it seems we should probably run these tests with

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Fri, Jul 8, 2016 at 4:46 AM, Tom Lane wrote: > Based on what I'm seeing so far, really 100K ought to be more than plenty > of slop for most architectures, but I'm afraid to go there for IA64. Searching for info on ia64 turned up this interesting thread:

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

I wrote: > Based on these numbers, I'd have no fear of reducing STACK_DEPTH_SLOP > to 256KB on x86_64. It would sure be good to check things on some > other architectures, though ... I went to the work of doing the same test on a PPC Mac: 182 Stack [ 8192K/ 40K] 25

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

I found out that pmap can give much more fine-grained results than I was getting before, if you give it the -x flag and then pay attention to the "dirty" column rather than the "nominal size" column. That gives a reliable indication of how much stack space the process ever actually touched, with

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > Ok, I managed to get __atribute__((destructor)) working and capitured > the attached pmap output for all the revisions. You can see the git > revision in the binary name along with a putative date though in the > case of branches the date can be deceptive. It

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Wed, Jul 6, 2016 at 2:34 PM, Tom Lane wrote: > > Conclusion: something we did in 8.4 greatly bloated the postmaster's > stack space consumption, to the point that it's significantly more than > anything a normal backend does. That's surprising and scary, because > it means

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > I did a similar(ish) test which is admittedly not as exhaustive as > using pmap. I instrumented check_stack_depth() itself to keep track of > a high water mark (and based on Robert's thought process) to keep > track of the largest increment over the previous

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Tue, Jul 5, 2016 at 8:48 PM, Tom Lane wrote: > Unfortunately the way I did (1) only works on systems with pmap; I'm not > sure how to make it more portable. I did a similar(ish) test which is admittedly not as exhaustive as using pmap. I instrumented check_stack_depth()

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Robert Haas writes: > On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane wrote: >> I'm pretty nervous about reducing that materially without any >> investigation into how much of the slop we actually use. > To me it seems like using anything based on

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane wrote: > Greg Stark writes: >> Poking at NetBSD kernel source it looks like the default ulimit -s >> depends on the architecture and ranges from 512k to 16M. Postgres >> insists on max_stack_depth being STACK_DEPTH_SLOP

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > Poking at NetBSD kernel source it looks like the default ulimit -s > depends on the architecture and ranges from 512k to 16M. Postgres > insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less > than the ulimit setting making it impossible to

[HACKERS] can we optimize STACK_DEPTH_SLOP

Poking at NetBSD kernel source it looks like the default ulimit -s depends on the architecture and ranges from 512k to 16M. Postgres insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less than the ulimit setting making it impossible to start up on architectures with a default of