Re: could not fork autovacuum worker process: No error

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

In response to

Responses

Browse pgsql-bugs by date

  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