Re: Storage Manager crash at mdwrite()

From: Tareq Aljabban <dee(dot)jay23(dot)me(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Storage Manager crash at mdwrite()
Date: 2012-03-19 21:14:53
Message-ID: CAGOe0a+HEZ0ihx33mrPEsigr02HikqAq8nX7xRuwG0b-QJCLng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 16, 2012 at 8:34 PM, Greg Stark <stark(at)mit(dot)edu> wrote:

> On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > There is a lot of difference between those two. In particular, it looks
> > like the problem you are seeing is coming from the background writer,
> > which is not running during initdb.
>
> The difference that comes to mind is that the postmaster forks. If the
> library opens any connections prior to forking and then uses them
> after forking that would work at first but it would get confused
> quickly once more than one backend tries to use the same connection.
> The data being sent would all be mixed together and they would see
> responses to requests other processes sent.
>

The opened connections thing was the first thing I thought of.. the HDFS
documentation claims the C interface is thread-safe..
However, since I noticed that different processes (having different process
IDs) are calling the mdwrite, then it might be a possibility.
I tried reconnecting to HDFS on every mdwrite request, but it didn't work
out.

> You need to ensure that any network connections are opened up *after*
> the new processes are forked.
>
> There are other things going on that could cause problems. initdb
> probably doesn't deal with many errors so it might not be casing any
> longjmps that happen when Postgres handles errors. I suspect it
> doesn't create any temporary files, etc.
>
> There's also a long history of threads not playing well with Postgres.
> I think that's overblown and I believe they should work fine. Most of
> it was caused by a bug in an old version of libc. But you do have to
> ensure that the other threads don't call any Postgres functions
> because the Postgres code is very much not thread-aware.
>
> --
> greg
>

I'm novice in PG, and if I got this one running then I'll have achieved
what I wanted to do without further digging in PG. So I was thinking if
there was a configuration option (or something similar) that will eliminate
(or reduce) the role the background writer process.. I believe it can be
one of the WAL options but I'm not sure.. Any suggestions?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2012-03-19 21:23:05 Re: sortsupport for text
Previous Message Alvaro Herrera 2012-03-19 20:57:19 Re: double free in current HEAD's pg_dump