Thread

1. PROC struct

   Myron Scott <mscott@sacadia.com> — 2001-01-30T09:25:19Z

   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
   
   
   

2. Re: PROC struct

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-05T16:36:52Z

   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
   
   

3. Re: PROC struct

   Myron Scott <mscott@sacadia.com> — 2001-02-05T20:56:58Z

   
   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