SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2) - Mailing list pgsql-general

Yes, obviously /storage/* isn't in the install dir, its the source file.
If you are using a port to compile postgres, it'd be in
/usr/ports/databases/postgresql7/work/postgresql-7.0.2/src/include

I'd suggest you do this: add a global backend_shmid_offset in ipc.c,
initialized to current default, and an option to postgres to put a value
there.

I'm not sure whether this option should be in pg_options or
postmaster.opts, and what's the name of it should be...Comments?

After you are done, send us a patch :)

On Fri, 5 Jan 2001, Dave VanAuken wrote:

> Knew about #1... and I'm not holding my breath for change gicing where
> the development on that angle is heading.
>
> In the installation directory for the jail i don't have the /storage
> directory, or for that matter the ipc.h file anywhere in the pgsql
> tree (both in the jail and host installations).  The version installed
> was 7.0.2
>
> What about hacking supplimentary installations and hardcoding new
> offsets for each subsequent installation of pgsql (can't even look
> into that until i detemine where the ipc.h code now exists).
>
> Appreciate the input...  the best description so far from the pgsql
> pov regarding the situation...  have been working almost entirely from
> the fbsd pov up until not and running out of options.  May be a wash
> for using pgsql in this situation.
>
> Dave
>
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Alex Pilosov
> Sent: Friday, January 05, 2001 1:50 PM
> To: Dave VanAuken
> Cc: pgsql-general@postgresql.org
> Subject: Re: running pgsql 7 under Jail'ed virtual machine on FreeBSD
> 4.2
>
>
> Here's the story about pgsql and jail:
>
> 1. FreeBSD shared memory is _really_ shared across all jail VMs. I
> think
> its not going to change, as this seems like a great way for processes
> to
> exchange data...But I could be wrong. :)
>
> 2. Postgres uses some funky math to determine which shmid to use for
> different memory allocations it needs. The problem with that it has no
> idea about jails and will not generate a different shmid for different
> processes, so postgres processes end up stepping on each other's toes.
>
> See include/storage/ipc.h, definition of SystemPortAddressGetIPCKey,
> and
> you'll understand what I mean.
>
> To properly fix this, I think this should be done:
>
> Another (optional) backend parameter which should determine offset
> (hardcoded now to 17491) for allocation of different shmids...
>
> comments? TODO?
>
>
> On Thu, 4 Jan 2001, Dave VanAuken wrote:
>
> > Have a FreeBSD 4.2 box...  have created two Virtual machines with
> the
> > jail process.
> > Apache and PHp configure and execute fine, but am having some
> > configuration and execution problems with pgsql... not sure if I am
> > missing something or if pgsql just cannot deal with being in the
> jail
> > and sharing the sysv memory
> >
> > Attempting to manually start the postmaster produces the following:
> >
> > %postmaster -i
> > IpcMemoryCreate: shmget failed (Function not implemented)
> key=5432010,
> > size=144, permission=700
> > This type of error is usually caused by an improper
> > shared memory or System V IPC semaphore configuration.
> > For more information, see the FAQ and platform-specific
> > FAQ's in the source directory pgsql/doc or on our
> > web site at http://www.postgresql.org.
> > IpcMemoryIdGet: shmget failed (Function not implemented)
> key=5432010,
> > size=144, permission=0
> > IpcMemoryAttach: shmat failed (Function not implemented) id=-2
> > FATAL 1:  AttachSLockMemory: could not attach segment
> > %
> >
> > Have modified the sysctl.conf file to allow usage of sysv memory,
> but
> > as it is already shared from the host machine, this may be causing
> > pgsql to barf on it.
> >
> > Searching for jail faq's and posts regarding this matter produces
> some
> > close, but not helpful posts regarding chroot'ed environments.
> >
> > Any insights, requests for details, and assistance are appreciated.
> >
> > Dave
> >
> >
>
>
>