Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8 - Mailing list pgsql-patches

From Kurt Roeckx
Subject Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
Date
Msg-id 20031202001153.GA16637@ping.be
Whole thread Raw
In response to Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
List pgsql-patches
On Mon, Dec 01, 2003 at 06:08:06PM -0500, Tom Lane wrote:
> Kurt Roeckx <Q@ping.be> writes:
> > On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote:
> >> After reviewing the proposed patch, I find it hard to believe that the
> >> patch would have fixed any such problem ---
>
> > It's not the key (key_t) that is the problem, but the size, which
> > used to be int but got replaced by a size_t.
>
> I don't see a problem there either.  We don't create shmem segments
> larger than 2Gb (and if we wanted to do so, this patch certainly
> isn't enough to get it done --- all the arithmetic for shmem sizing
> is int).

You're right that it shouldn't cause any problems because of the
promotion rules.  But changing the size to an size_t wouldn't be
a bad thing.

He seems to have changed this too:
- typedef uint32 IpcMemoryKey;
+ typedef size_t IpcMemoryKey;

That really should be a key_t.  Can't we use a key_t on systems
that have it?  The oldest sources I could find for shmget() all
said key_t.  And typedef key_t to an int for those that don't
have it?


Kurt


pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: introduce "default_use_oids"
Next
From: Sean Chittenden
Date:
Subject: Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?