Re: sysv_shmem potential problem
От | lsunley@mb.sympatico.ca |
---|---|
Тема | Re: sysv_shmem potential problem |
Дата | |
Msg-id | 0I9L0044CU9UQJ@l-daemon обсуждение исходный текст |
Ответ на | Re: sysv_shmem potential problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I see, The shmem.c implementation I am using returns the OS/2 memory ID which also happens to be the base address of the allocated memory. Bug in shmem.c code then Thanks Lorne In <12098.1104526404@sss.pgh.pa.us>, on 12/31/04 at 03:53 PM, Tom Lane <tgl@sss.pgh.pa.us> said: >lsunley@mb.sympatico.ca writes: >> I am using the sysv_shmem.c shared memory allocation api for os/2 and I >> ran into a problem when OS/2 allocates shared memory over the 2 gigabyte >> address boundary. >> The existing sysv_shmem.c tests for the return address of the segment as >> less than 0 and determines that a negative indicates an error. >shmget returns an ID, not an address. I quote from the Single Unix Spec: > Upon successful completion, shmget() returns a non-negative integer, > ^^^^^^^^^^^^ > namely a shared memory identifier; otherwise, it returns -1 and errno > will be set to indicate the error. >While your change might be harmless, it should not be necessary, and it >certainly shouldn't have anything to do with 2gig address boundaries. > regards, tom lane -- ----------------------------------------------------------- lsunley@mb.sympatico.ca -----------------------------------------------------------
В списке pgsql-hackers по дате отправления: