pgsql 7.4 on minimal environment

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.

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.

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

Hi Keith, everyone,

----- Original Message -----
From: "Keith C. Perry" <netadmin@vcsn.com>
To: "Victor B. Berdin" <vic@digi.com.ph>
Cc: <pgsql-general@postgresql.org>
Sent: Monday, December 08, 2003 2:20 AM
Subject: Re: [GENERAL] pgsql 7.4 on minimal environment

OK, I've got it! What's causing the failure is that I've ran
'upx -9' on my PG binaries. And this trashed it! Thanks
for your reply. Will experiment further on using upx :o).

Best regards - Vic

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

I'm sure you've caugth my last message as I was too hasty to post my
replies right away. Anyways, it turned out that the only cause of my
problem is that I 've applied "upx" on the binaries.

Even more specifically, it sounds like the problem was with applying
"upx" to things that weren't binaries but shell scripts.

I don't know what upx is supposed to do, but one would think that if
it's a tool for modifying binaries, it should have enough smarts to not
mangle files that are not binaries. Perhaps you should file a bug
report with the upx developers.

regards, tom lane

Hi Keith, everyone,

I'm sure you've caugth my last message as I was too hasty to post my
replies
right away. Anyways, it turned out that the only cause of my problem is
that
I 've applied "upx" on the binaries. It works though for my standard
Slackware
setup, but it does not for the busybox environment. Reverting the
affected
binaries to their original (un-upx'd) form fixes the problem.
Even though it may no longer be relevant, here're some more details as
to
what I'm trying to do (which I also find very exciting):

----- Original Message -----
From: "Keith C. Perry" <netadmin@vcsn.com>
To: "Victor B. Berdin" <vic@digi.com.ph>
Cc: <pgsql-general@postgresql.org>
Sent: Monday, December 08, 2003 9:24 AM
Subject: Re: [GENERAL] pgsql 7.4 on minimal environment

What does "dev't" mean? I'm talking that to mean development machine.

If so,

Yes, that's exactly what it means.

then I'm not understanding why (or how for that matter) you are

embedding the

environment. Please advise...

Ok, the minimal environment will host a sort of POS (system) that uses
PGSQL
as its DB. We find PGSQL as the most rich, mature, stable, and fast open
source
DB around. Trully, it is :o).

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.

Well actually, we're done with regressions, for our older products that
uses
PGSQL 7.1.2 at least. And now that 7.4 is here, it's worth giving a shot
at
embedding it for our newer products. And I strongly believe it will
work!
Anyways, we can always revert to the older versions if it doesn't. And
btw,
this may sound crazy but, I also had XF86-4.30 running on the said
minimal/
busybox environment, including the standard MozillaFirebird (just for
kicks).
The environment still requires a lot of stripping though, but after
seeing "initdb"
and "pg_ctl" finally work, I'm all smiles already :o).

Once more, many thanks!

Best regards - Vic

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

Hi Keith, everyone,

I'm sure you've caugth my last message as I was too hasty to post my
replies
right away. Anyways, it turned out that the only cause of my problem is
that
I 've applied "upx" on the binaries. It works though for my standard
Slackware
setup, but it does not for the busybox environment. Reverting the
affected
binaries to their original (un-upx'd) form fixes the problem.
Even though it may no longer be relevant, here're some more details as
to
what I'm trying to do (which I also find very exciting):

----- Original Message -----
From: "Keith C. Perry" <netadmin@vcsn.com>
To: "Victor B. Berdin" <vic@digi.com.ph>
Cc: <pgsql-general@postgresql.org>
Sent: Monday, December 08, 2003 9:24 AM
Subject: Re: [GENERAL] pgsql 7.4 on minimal environment

What does "dev't" mean? I'm talking that to mean development machine.

If so,

Yes, that's exactly what it means.

then I'm not understanding why (or how for that matter) you are

embedding the

environment. Please advise...

Ok, the minimal environment will host a sort of POS (system) that uses
PGSQL
as its DB. We find PGSQL as the most rich, mature, stable, and fast open
source
DB around. Trully, it is :o).

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.

Well actually, we're done with regressions, for our older products that
uses
PGSQL 7.1.2 at least. And now that 7.4 is here, it's worth giving a shot
at
embedding it for our newer products. And I strongly believe it will
work!
Anyways, we can always revert to the older versions if it doesn't. And
btw,
this may sound crazy but, I also had XF86-4.30 running on the said
minimal/
busybox environment, including the standard MozillaFirebird (just for
kicks).
The environment still requires a lot of stripping though, but after
seeing "initdb"
and "pg_ctl" finally work, I'm all smiles already :o).

Once more, many thanks!

Best regards - Vic

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Sounds very interesting. I hope you get around that problem with upx
compression. I would have thought that the busybox stuff wouldn't effect you.
Maybe the library need for upx is conflicting with something. In any event good
luck!

--
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