Re: Debug strategy for musl Postgres?

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: John Mudd <johnbmudd(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Subject: Re: Debug strategy for musl Postgres?
Date: 2014-04-14 18:06:52
Message-ID: 534C23BC.6000906@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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.

Stefan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-04-14 19:11:39 Re: BUG #10006: 'DO INSTEAD UPDATE' error
Previous Message John R Pierce 2014-04-14 17:54:23 Re: Fwd: cant insert into a post gre sql table...Can u please help in fixing this

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-14 18:18:27 Re: Signaling of waiting for a cleanup lock?
Previous Message Andres Freund 2014-04-14 17:51:44 Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: Problem with txid_snapshot_in/out() functionality)