Fwd: [BUGS] Debug strategy for musl Postgres?

From: John Mudd <johnbmudd(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Fwd: [BUGS] Debug strategy for musl Postgres?
Date: 2014-04-15 02:48:34
Message-ID: CAGDMk9EMp+CCEE+xZ+hLGeUgyi+0t+O24zTDkZtHnzstqNw+eg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, Apr 14, 2014 at 2:06 PM, Stefan Kaltenbrunner <
stefan(at)kaltenbrunner(dot)cc> wrote:

> On 04/13/2014 10:19 PM, John Mudd wrote:
> >
> > On Sun, Apr 13, 2014 at 12:04 PM, Euler Taveira <euler(at)timbira(dot)com(dot)br
> > <mailto:euler(at)timbira(dot)com(dot)br>> wrote:
> >
> > On 13-04-2014 00:40, John Mudd wrote:
> > > I built Postgres 9.3.4 from source on top of the musl C library,
> > > http://www.musl-libc.org/
> > > I also built zlib, bzip2, ncurses, openssl, readline and Python
> > using musl
> > > as a foundation for Postgres.
> > >
> > This is not a bug. This kind of discussion belongs to -hackers.
> >
> > While reading this email, I give musl a try. I'm using Debian jessie
> > which contains musl 1.0.0. I compiled the source (git master) using
> > CC="musl-gcc" and disabled zlib and readline. It passed all
> regression
> > tests. I also tried a pgbench which ran like a charm. (After
> installed
> > the binaries I had to set the libray path for musl in
> > /etc/ld-musl-x86_64.d.)
> >
> > > I'm using musl to increase the portability of the Postgres binary.
> > I build
> > > on Ubuntu 13.10 but will runs on older Linux boxes.
> > >
> > Could you give details about your architecture?
> >
> >
> > Built on 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:25:33 UTC 2013
> > i686 i686 i686 GNU/Linux
> > Runs fine there.
> >
> > Moved postgres install directory to 2.4.21-4.EL #1 Fri Oct 3 18:13:58
> > EDT 2003 i686 i686 i386 GNU/Linux
> > Not working fully there.
> > Note: It's says 2.4 kernel but I've been told that's misleading. The
> > kernel has upgrades that make it effectively 2.6.
>
> This looks like a RHEL3 version number, and while that kernel was kind
> of creepy thing with a lot of patches (also from the 2.6 era) backport
> it is definititly not a 2.6 kernel(also note that 2.6.0 was released in
> december of 2003 while RHEL 3 was released in october that year. Juding
> from the version number this also seems to be based on the very first
> RHEL3 kernel missing all follow up bugfixed during the RHEL3 lifetime.
>
> So I would be very much not surprised if a modern and young C-library
> running on a >10 year old kernel that never looked like the upstream
> kernel misbehaved with a complex userspace app like postgresql.
>
>
Update:
I contacted musl developers, received a one line patch to the
gettimeofday() fallback code, rebuilt the musl libc, copied the lib to my
old linux box and Postgres is running well now.

=======================
All 136 tests passed.
=======================

It's interesting that when I built Postgres on this same old Linux but it
fails to run.

============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============

pg_regress: postmaster did not respond within 60 seconds

Building with musl on a modern Linux works on an old Linux. But building
Postgres on the old Linux with the native libc gives me a broken Postgres.
That's why I'm interested in musl libc.

>
>
> Stefan
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message digoal 2014-04-15 07:02:42 BUG #10035: PostgreSQL nodes's estimate rows bug? when alter column set statistics 0
Previous Message Heikki Linnakangas 2014-04-14 19:35:04 Re: BUG #10014: Does not work PQfn in libpq with array

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-04-15 03:07:31 Re: [COMMITTERS] pgsql: Add TAP tests for client programs
Previous Message Andrew Dunstan 2014-04-15 02:30:48 Re: [COMMITTERS] pgsql: Add TAP tests for client programs