"Cyril VELTER" <[EMAIL PROTECTED]> writes:
> I find the semaphore API quite clean but have some question on the
> Shared memory one. The Id's passed to PGSharedMemoryIsInUse aren't clear to
> me. How id1 and id1 are related to the port parameter of
> PGSharedMemoryCreate ?
You can define 'em however you want. For SysV shmem they are the shmem
key and id.
> Also why not do the header fillup outside of PGSharedMemoryCreate ?
Well, (a) I wasn't really concerned about defining an all-new API for
shmem, and (b) I think the header is largely dependent on the semantics
of SysV shmem anyway. A different shmem implementation might need
different fields in there.
> What about using an API similar to the sema one :
> PGShmemHeader * PGSharedMemoryCreate(PGShmem shmem,uint32 size, bool
> makePrivate, int memKey);
> bool PGSharedMemoryIsInUse(PGShmem shmem);
How does that solve the problem of determining whether a *previously*
created shmem block is still in use? The point here is to be able to
trace the connection from a data directory to active backends via their
connections to a shared memory block --- take a look at
RecordSharedMemoryInLockFile, which is the flip side of
SharedMemoryIsInUse.
> On a side note, after these API change, Beos will still need an Hack for
> shared memory, because all shared memory segments are in copy on write mode
> in the forked process. One solution could be to have an explicit attach call
> in the forked process :
> PGSharedMemoryAttach(PGShmem shmem);
No strong feelings about this --- it looks like the same BeOS-specific
hack under a different name ;-)
> This will allow the following calls for each fork to removed :
> beos_before_backend_startup
> beos_backend_startup_failed
> beos_backend_startup
How so? If those calls were needed before, why won't all three still
be needed?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
