Re: pgsql 7.4 on minimal environment - Mailing list pgsql-general

Quoting "Victor B. Berdin" <vic@digi.com.ph>:

> Hi Keith, everyone,
>
> > Thats interesting since "ldd initdb" and "ldd pg_ctl" show that there
> aren't any
> > .so's needed.  Have you tried using the debugger to see whats is
> causing the fault.
>
> And this problem didn't exist on my old minimal system (Linux
> 2.2.20/libc-2.1.3)
> pg7.1.2 either. All of which are running from pure ramdisk.

Ok, keep in mind though, Tom said those are all shell scripts so, you might want
to parse through them and see whats going on.

> > If you are trying to build a "runtime" (Linux and PostgreSQL running
> live from a
> > CD) you might want to use install a minimum files system first and
> then merge
> > that filesystem that into something like the Slackware disc 2 CD.
> I've done
> > that before to make customized runtime/recovery CD's.
>
> Well, sort of. What i'm actually trying to create is an embedded
> environment
> using a Slackware 9 (kernel upgraded) setup as dev't machine.

What does "dev't" mean?  I'm talking that to mean development machine.  If so,
then I'm not understanding why (or how for that matter) you are embedding the
environment.  Please advise...

> > For PostgreSQL, you'd need a way to put it on a filesystem that it
> thinks is
> > writeable so you'd probably need a kernel that supports a very large
> ramdisk.
> > I'm just guessing since I've never attempted to put PostgreSQL on
> runtime CD but
> > this has been discussed before so maybe someone else has had some
> success.
>
>
> Ok, here're some more details:
> My min environment is comprised of images (initrd, tgz, and cramfs) that
> boots off
> from a compact flash and then exploded/mounted into ramdisk. The tgz
> image tree
> serves as a backupable image, and holds all common writeable paths. It
> will also
> hold the future postgres database if it will be required that the DB
> should be
> backupable.
> The Postgres7.4 bins & libs (/usr/local/pgsql/*) on the other hand, is a
> cramfs
> image, and thus, is read-only. An attempt to create a DB on /tmp/db
> (/tmp is on ramdisk) yields to the "SIGSEGV" message. Any command
> involving
> "initdb", "pg_ctl" and "initlocation" yields to the said error. I
> repeat, this environment
> uses almost pure busybox (only "mount" is taken from slackware).
>
> Anymore hints/advise is very much appreciated.
>
> TIA & best regards - Vic

Ok, It's been awhile since I've messed with busybox.  At the time, I found it to
be very confusing and awkward to build products from scratch.  However, I have
notice of previous Slackware installs that the busybox builds did not have have
"full" commands.  For example a command like "ls -lh" on the Slackware 9.0
bootdisks (NOT the CD) did not work because the "h" parameter was not recognized
by the command.  Of course in a full install it would be.

If there are minor differences there, there *could* be minor differences
elsewhere.  Again, I don't quite understand busybox that well so maybe this is
not an issue for you.  SEGV are memory violation errors so I'm wondering if how
you're using the ramdisk is an issue.  I would think that if the entire runtime
FS was not on the ramdisk you would get a problem.  At the very least, /tmp and
/var also would need to be there too.  A certain test would be take a test box
with pg on in run some queries (regression tests would probably be a good
candidate) and then do a "find / -cmin -5".  The 5 should be ajusted for the
amount of time you were using the database.  That command would give you a idea
of what paths needs to be on the ramdisk.

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com