Re: [HACKERS] why do shmem attach?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Developers List <hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] why do shmem attach?
Date: 1999-09-20 13:44:09
Message-ID: 13479.937835049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> Though, AttachSharedMemoryAndSemaphores():
> if (key == PrivateIPCKey)
> {
> CreateSharedMemoryAndSemaphores(key, 16);
> return;
> }
> ... and useless shmem attachment stuff follows after this ...

That path is used for a standalone backend. Is that useless?

> Cleanup is still required, but subj is closed, thanks -:)

I don't think it's worth messing with either. It'd be nice for code
beautification purposes to (a) combine the three shared-mem segments
we currently have into one, and (b) rely on the postmaster's having
attached the segment, so that all backends will see it at the same
location in their address space, which would let us get rid of the
MAKE_OFFSET/MAKE_PTR cruft. But getting the full benefit would
require cleaning up a lot of code, and it just doesn't seem like
a high-priority task. I'm also a little worried that we'd be
sacrificing portability --- some day we might be glad that we can
move those segments around...

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Leon 1999-09-20 13:50:12 Re: [HACKERS] All things equal, we are still alot slower then MySQL?
Previous Message Vadim Mikheev 1999-09-20 13:40:45 Re: [HACKERS] Status on Jan Wieck