From: | lsunley(at)mb(dot)sympatico(dot)ca |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sysv_shmem potential problem |
Date: | 2004-12-31 19:55:26 |
Message-ID: | 0I9L0044CU9UQJ@l-daemon |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)1104526404(at)sss(dot)pgh(dot)pa(dot)us>, on 12/31/04
at 03:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> said:
>lsunley(at)mb(dot)sympatico(dot)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(at)mb(dot)sympatico(dot)ca
-----------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Sibtay Abbas | 2004-12-31 19:57:14 | exception handling in plpgsql |
Previous Message | Tom Lane | 2004-12-31 19:52:33 | Re: 'COPY ... FROM' inserts to btree, blocks on buffer writeout |