Postgres Pro
Downloads
Home   >   mailing lists

Thread: PROC struct

PROC struct

From
Myron Scott
Date:
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

Re: PROC struct

From
Tom Lane
Date:
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

Re: PROC struct

From
Myron Scott
Date:
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