Thread: PostgreSQL 8.0.0beta1 and diet libc

Hello,

I'm trying to PostgreSQL 8.0.0beta1 together with diet libc
<http://www.fefe.de/dietlibc/>. diet libc is a small libc designed for
getting small, statically linked binaries. In the past, this has often
shown that programs were running faster. So, my current goal is to get
PostgreSQL running together with diet libc. So far, PostgreSQL compiles
and links when you configure PostgreSQL with the following parameters:

CC="/opt/diet/bin/diet -Os gcc -D_BSD_SOURCE -nostdinc" ./configure \
--without-readline --without-zlib --disable-shared

(you can remove --without-{readline,zlib} if you installed these two
libraries for diet libc).

One problem that I have with installation is the following thing:
./zic -d /usr/local/pgsql/share/timezone ./data/africa ./data/antarctica \
./data/asia ./data/australasia ./data/europe ./data/northamerica \
./data/southamerica ./data/pacificnew ./data/etcetera ./data/factory \
./data/backward ./data/systemv ./data/solar87 ./data/solar88 \
./data/solar89
"./data/europe", line 219: line too long
make[1]: *** [install] Error 1
make[1]: Leaving directory
`/usr/src/pgsql/postgresql-8.0.0beta1/src/timezone'
make: *** [install] Error 2

But that's fixed easily by deleting a comment that is too long (same
thing in line 1025, BTW). I then followed the steps described in 
http://www.postgresql.org/docs/7.4/static/installation.html.

And that's where I'm stuck right now:

postgres@tintifax:/usr/local/pgsql$ bin/initdb -D data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

fixing permissions on existing directory data ... ok
creating directory data/global ... ok
creating directory data/pg_xlog ... ok
creating directory data/pg_xlog/archive_status ... ok
creating directory data/pg_clog ... ok
creating directory data/pg_subtrans ... ok
creating directory data/base ... ok
creating directory data/base/1 ... ok
creating directory data/pg_tblspc ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 50
creating configuration files ... ok
creating template1 database in data/base/1 ... FATAL:  XX000: failed to
initialize lc_monetary to "C"
LOCATION:  InitializeGUCOptions, guc.c:2337
child process exited with exit code 1
initdb: failed
initdb: removing contents of data directory "data"
postgres@tintifax:/usr/local/pgsql$

As an important note you have to know that diet libc's support for all
the NLS and i18n/l10n-related stuff is largely incomplete and works so
far that common software compiles and runs (this is also one of diet
libc's secondary design goals, to keep out a lot of complexity,
especially when it's about features you will most likely not need on
embdded Linux systems). Any hints on how to get PostgreSQL running
together with diet libc anyway?

Thanks in advance,
Andreas Krennmair

Andreas Krennmair <netnews@synflood.at> writes:
> creating template1 database in data/base/1 ... FATAL:  XX000: failed to
> initialize lc_monetary to "C"
> LOCATION:  InitializeGUCOptions, guc.c:2337
> child process exited with exit code 1

> As an important note you have to know that diet libc's support for all
> the NLS and i18n/l10n-related stuff is largely incomplete and works so
> far that common software compiles and runs 

[ shrug ]  If it returns an error when someone tries to set the locale
to "C", that is *not* a good-enough implementation of the ANSI/ISO C
standard.  Fix the library.
        regards, tom lane

* Tom Lane <tgl@sss.pgh.pa.us> [gmane.comp.db.postgresql.devel.general]:
>  Andreas Krennmair <netnews@synflood.at> writes:
> > creating template1 database in data/base/1 ... FATAL:  XX000: failed to
> > initialize lc_monetary to "C"
> > LOCATION:  InitializeGUCOptions, guc.c:2337
> > child process exited with exit code 1
>  
> > As an important note you have to know that diet libc's support for all
> > the NLS and i18n/l10n-related stuff is largely incomplete and works so
> > far that common software compiles and runs 
>  
>  [ shrug ]  If it returns an error when someone tries to set the locale
>  to "C", that is *not* a good-enough implementation of the ANSI/ISO C
>  standard.  Fix the library.

[x] Done. :-)

I did some research and submitted a patch to diet libc, the only other
issue that I had with PostgreSQL was a minor one, which I fixed with a
small patch to PostgreSQL:

http://synflood.at/patches/pgsql-diet.diff

The first fix is that PostgreSQL relies on that, when reading the output
of postgres -V, all the output can be read with a single read call (or
whatever call is used, it comes down to read(2) in the end) when called
from initdb. This is not the case with diet libc, as the puts
implementation in diet libc does two write calls, with the second write
call happening with a closed pipe. Changing the puts to printf removes
this problem, optionally you could change the format string to "%s\n" to
get the original output (although the patch doesn't break PostgreSQL
w/o diet libc, AFAICS).

The other modifications in src/timezone/data/europe are a  quick fix
because I got the error message "line too long" when trying to do a make
install.

Regards,
Andreas Krennmair

Andreas Krennmair <netnews@synflood.at> writes:
> The first fix is that PostgreSQL relies on that, when reading the output
> of postgres -V, all the output can be read with a single read call (or
> whatever call is used, it comes down to read(2) in the end) when called
> from initdb.

Hmm.  This is a fair point.  Shouldn't pipe_read_line() loop until it's
detected EOF?  I'm willing to fix the Unix half of it but I dunno about
the Windows half.

> The other modifications in src/timezone/data/europe are a  quick fix
> because I got the error message "line too long" when trying to do a make
> install.

Can you say where that error message is coming from?  Because I'd say
that we should fix the limitation, not kluge the data files ...
        regards, tom lane