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 stac
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 ]
> 136 80
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 return a 0 in the bi
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
> -O0 because th
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:
https://www.postgresql.org/message-id/2
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 Sta
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 r
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 looks to me like
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 the postmaster is *m
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 checked stack dept
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() itself to keep track of
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 stack_rlimit/2 is pretty
> risky for the reason that y
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 -- ie 512kB -- less
>> than the uli
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 start up on
> archit
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 512k
15 matches
Mail list logo
