PROC struct

Started by Myron Scottabout 25 years ago3 messagesbugs
Jump to latest
#1Myron Scott
mscott@sacadia.com

Hi,

May I suggest that watiHolder and waitLock pointers
in the proc struct in proc.h be changed from direct
pointers to SHMEM_OFFSET. They are both shared memory
structures in a shared memory structure and it would
be more consistent to make these SHMEM_OFFSET. Direct
pointers will be a problem if another process which is
not the result of a fork tries to attach to the shared memory.
The Direct pointers will not be valid for in this case.

Thanks,

Myron Scott
mkscott@sacadia.com

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Myron Scott (#1)
Re: PROC struct

Myron Scott <mscott@sacadia.com> writes:

May I suggest that watiHolder and waitLock pointers
in the proc struct in proc.h be changed from direct
pointers to SHMEM_OFFSET. They are both shared memory
structures in a shared memory structure and it would
be more consistent to make these SHMEM_OFFSET. Direct
pointers will be a problem if another process which is
not the result of a fork tries to attach to the shared memory.

I don't really foresee that that's an issue --- any process
we might conceivably want to have reading the shmem would be
spawned by the postmaster anyway. I've actually been thinking
about ripping out the shmem-offset-to-pointer-and-back conversions
on the grounds of code simplification, readability, reliability
(the compiler cannot detect whether you are casting a reconverted
SHMEM_OFFSET to the wrong pointer type), and speed.

regards, tom lane

#3Myron Scott
mscott@sacadia.com
In reply to: Tom Lane (#2)
Re: PROC struct

On Mon, 5 Feb 2001, Tom Lane wrote:

Myron Scott <mscott@sacadia.com> writes:

May I suggest that watiHolder and waitLock pointers
in the proc struct in proc.h be changed from direct
pointers to SHMEM_OFFSET. They are both shared memory
structures in a shared memory structure and it would
be more consistent to make these SHMEM_OFFSET. Direct
pointers will be a problem if another process which is
not the result of a fork tries to attach to the shared memory.

I don't really foresee that that's an issue --- any process
we might conceivably want to have reading the shmem would be
spawned by the postmaster anyway. I've actually been thinking
about ripping out the shmem-offset-to-pointer-and-back conversions
on the grounds of code simplification, readability, reliability
(the compiler cannot detect whether you are casting a reconverted
SHMEM_OFFSET to the wrong pointer type), and speed.

regards, tom lane

Thanks for looking into this. I ran into this while working on a threaded
version of Postgres. I start a postmaster so I can use psql
and then start the multithreaded Postgres which attaches to the shared mem
created by the postmaster. This is not a big deal but maybe a note in the
header would be helpful to future tinkerers.

Thanks,

Myron Scott
mkscott@sacadia.com