On Mon, Sep 2, 2013 at 6:52 PM, Andres Freund <and...@2ndquadrant.com> wrote: > Not sure whether you mean non-windows EXEC_BACKEND isn't going to be > supported for much longer or that it already has problems.
I'm not sure what Noah was getting at, but I have used EXEC_BACKEND twice now during development, in situations where I would have needed a Windows development otherwise. So it's definitely useful, at least to me. But on my MacBook Pro, you have to compile it with -fno-pie (I think that's the right flag) to disable ASLR in order to get reliable operation. I imagine such problems will become commonplace on more and more platforms as time wears on. > I guess my point is that if we want to develop stuff that requires > reliable addresses, we should build support for that from a low level > up. Not rely on a hack^Wlayer ontop of the actual dynamic shared memory > API. > That is, it should be a flag to dsm_create() that we require a fixed > address and dsm_attach() will then automatically use that or die > trying. Requiring implementations to take care about passing addresses > around and fiddling with mmap/windows api to make sure those mappings > are possible doesn't strike me to be a good idea. > > In the end, you're going to be the primary/first user as far as I > understand things, so you'll have to argue whether we need fixed > addresses or not. I don't think it's a good idea to forgo this decision > on this layer and bolt on another ontop if we decide it's neccessary. I didn't intend to punt that decision to another layer so much as another patch and a more detailed examination of requirements. IME, given a choice between something that is 99% reliable and provides more functionality, or something that is 99.99% reliable and provides less functionality, this community picks the latter every time. And that's why I've left out any capability to insist on a fixed address from this patch. It would be nice to have, to be sure. But it also would take more work and add more complexity, and I don't have a clear sense that that work would be justified. Now, we might get to a point where it seems clear that we're not going to get any further with parallelism without adding a capability for fixed-address mappings. If that happens, I think that's the time to come back to this layer and add that capability. But right now it doesn't seem essential. Now, having said that, I didn't see any particular reason to bury the ability to pass mmap() or shmat() a *preferred* address. But IJWH. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
