> > > We add those to all links, mostly because it is too confusing to
> > > do it per link. It doesn't hurt anything because it is
> > > dynamically linked, so doesn't take any disk space, and in fact
> > > is never called.
> >
> > My concern wasn't for disk space, but for symbol resolution times
> > and unnecessary VM page table space. Does the backend fork() or
> > exec() a copy of itself when a new connection comes in? I thought
> > it was exec() for some reason. Anyway, given how easy it is to
> > change the LDFLAGS, I was thinking about chasing down where
> > postgres is linked and splitting apart LDFLAGS into two sets of
> > LDFLAGS: LDFLAGS_CLI and LDFLAGS (or LDFLAGS_DAEMON, or some
> > such). It's chump, but a few ms here and there, or a little more
> > IO there eventually add up, especially in the arena of on
> > connection times.
>
> Backend only forks(). I think you would be better off using
> Makefile macros to _remove_ those two libraries.
>
> I see this:
>
> $(filter crypt.o getaddrinfo.o inet_aton.o snprintf.o strerror.o path.o thread.o, $(LIBOBJS))
>
> Seems you need the reverse.
Ah, well, if it fork()'s, then I don't really care. The best
remaining argument for this would be to reduce the total size of a
machine's VM page table size and possibly the expense of switching
contexts between procs, but that's a pretty weak argument for only .5M
of shared RAM. For some reason I thought it exec()'ed a child with
the args necessary for it to read in a postgresql.conf. Looks like
the comment in backend/storage/ipc/ipci.c is out of date then:
* AttachSharedMemoryAndSemaphores* Attaches to the existing shared resources when exec()'d off*
by the postmaster.
-sc
--
Sean Chittenden