Amit Kapila <amit.kapil...@gmail.com> writes:
> Sure. I think it is slightly tricky because specs don't say clearly
> how ASLR can impact the behavior of any API and in my last attempt I
> could not reproduce the issue.
> I can try to do basic verification with the patch you have proposed,
> but I fear, to do the actual tests as suggested by you is difficult as
> it is not reproducible on my machine, but I can still try.
Yeah, being able to reproduce the problem reliably enough to say whether
it's fixed or not is definitely the sticking point here. I have some
ideas about that:
1. Be sure to use Win32 not Win64 --- the odds of a failure in the larger
address space are so small you'd never prove anything. (And of course
it has to be a version that has ASLR enabled.)
2. Revert 7f3e17b48 so that you have an ASLR-enabled build.
3. Crank shared_buffers to the maximum the machine will allow, reducing
the amount of free address space and improving the odds of a collision.
4. Spawn lots of sessions --- pgbench with -C option might be a useful
testing tool.
With luck, that will get failures often enough that you can be pretty
sure whether a patch improves the situation or not.
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
