From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Tomasz Szypowski <tomasz(dot)szypowski(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: could not fork autovacuum worker process: No error |
Date: | 2017-04-02 15:58:57 |
Message-ID: | 27928.1491148737@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> I think that the OP here is asking for a solution where our shared
> memory implementation is not messed up with ASLR enabled. And we don't
> have a clear solution for that yet.
Yeah. I don't know anything about the address space layout under Windows,
but it occurs to me to ask how much of the address space their version of
ASLR thinks it can chew up. Maybe we could fix this by explicitly asking
for the shmem block to be mapped at the top of memory always, or something
along that line. Perhaps it would only be fixable that way under Win64,
but that would still be a good step forward.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Szypowski | 2017-04-02 17:51:59 | Re: could not fork autovacuum worker process: No error |
Previous Message | David G. Johnston | 2017-04-01 17:57:33 | Re: BUG #14608: no index scan with NOT IN and ENUM |