Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
От | Kurt Roeckx |
---|---|
Тема | Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8 |
Дата | |
Msg-id | 20031202001153.GA16637@ping.be обсуждение исходный текст |
Ответ на | Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
|
Список | 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 по дате отправления: