Hi

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.

I have this patch (below) ifdef'd for OS/2 but I thought that there may be
a problem on other platforms that can allocate shared memory over the 2
gig boundary

The existing code is

if (shmid < 0)

Index: sysv_shmem.c
================================================== =================
RCS file: /projects/cvsroot/pgsql/src/backend/port/sysv_shmem.c,v
retrieving revision 1.41
diff -r1.41 sysv_shmem.c
80a81,85
> #ifdef __OS2__
> /* shared memory address may be allocated over 2 gig and will negative */
> /* so test for the explicit -1 return */
> if (shmid == -1)
> #else
81a87
> #endif


--
-----------------------------------------------------------
lsunley@mb.sympatico.ca
-----------------------------------------------------------


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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
-----------------------------------------------------------


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster