Re: Solved? Re: 8.2.4 signal 11 with large transaction

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Solved? Re: 8.2.4 signal 11 with large transaction
Date: 2007-07-20 19:39:26
Message-ID: 20070720153926.da2557d3.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

In response to Bill Moran <wmoran(at)collaborativefusion(dot)com>:

> In response to "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>:
[snip]
> I'm starting to wonder if the OS could be sending the sig 11?
>
> ... time warp ...
>
> Yup, that was it. The OS was limiting the amount of memory a single
> process could use via kern.maxdsiz (FreeBSD). This was evident with
> ulimit -d.
>
> So, the fact remains that PG 8.1 returns an out of memory error when
> it hits this, and PG 8.2 coredumps. Is the 8.2 behaviour expected/
> planned? The out of memory error I would expect, the coredump I
> would not.

It just occurred to me that there's another wildcard in this one.
The 8.1 system I tested was on FreeBSD 5.5, while both 8.2 systems
were running on FreeBSD 6.2. I wonder if FreeBSD has changed
which signal gets sent on memory exhaustion?

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-07-20 20:05:39 Re: 8.2.4 signal 11 with large transaction
Previous Message Bill Moran 2007-07-20 19:28:25 Solved? Re: 8.2.4 signal 11 with large transaction

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-07-20 19:52:02 Re: Memory leak in vac_update_relstats ?
Previous Message Bill Moran 2007-07-20 19:28:25 Solved? Re: 8.2.4 signal 11 with large transaction