Tom Lane wrote:
Seneca Cunningham [EMAIL PROTECTED] writes:
I don't have a core, but here's the CrashReporter output for both
of jackal's failed runs:
Wow, some actual data, rather than just noodling about how to get it ...
thanks!
...
11 postgres 0x0022b2e3
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
fwiw - I can trigger that issue now pretty reliably on a fast Opteron
box (running Debian Sarge/AMD64) with make regress in a loop - I seem to
be able to trigger it in about 20-25% of the runs.
the resulting core however looks totally stack
On Sun, Dec 31, 2006 at 05:43:45PM +0100, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
What you seem to have here is infinite recursion during relcache
initialization. That's surely not hard to believe, considering I just
whacked that code around, and indeed changed some of the tests that
Seneca Cunningham [EMAIL PROTECTED] writes:
I don't have a core, but here's the CrashReporter output for both
of jackal's failed runs:
Wow, some actual data, rather than just noodling about how to get it ...
thanks!
...
11 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496)
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
here's a quick untested patch for buildfarm that Stefan might like to try.
Note that not all core files are named core. On some Linux distros,
it's configured to be core.PID by default.
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm actually wondering if unlimiting core might not be a useful switch
to provide on pg_ctl, as long as the platform has setrlimit().
Not a bad thought; that's actually one of the reasons that I still
usually use a handmade script rather than pg_ctl for
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm actually wondering if unlimiting core might not be a useful switch
to provide on pg_ctl, as long as the platform has setrlimit().
Not a bad thought; that's actually one of the reasons that I still
usually use a handmade script
Tom Lane wrote:
Several of the buildfarm machines are exhibiting repeatable signal 11
crashes in what seem perfectly ordinary queries. This started about
four days ago so I suppose it's got something to do with my
operator-families patch :-( ... but I dunno what, and none of my own
machines
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Several of the buildfarm machines are exhibiting repeatable signal 11
crashes in what seem perfectly ordinary queries.
no stack trace yet however impala at least seems to be running out of
memory (!) with 380MB of RAM and some
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Several of the buildfarm machines are exhibiting repeatable signal 11
crashes in what seem perfectly ordinary queries.
no stack trace yet however impala at least seems to be running out of
memory (!) with 380MB
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
... Maybe something is causing a dramatic
increase in memory usage that is causing the random failures (in impalas
case the OOM-killer actually decides to terminate the postmaster) ?
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
... Maybe something is causing a dramatic
increase in memory usage that is causing the random failures (in impalas
case the OOM-killer actually decides to terminate
Tom Lane wrote:
Actually ... one way that a memory overconsumption bug could manifest
as sig11 would be if it's a runaway-recursion issue: usually you get sig11
when the machine's stack size limit is exceeded. This doesn't put us
any closer to localizing the problem, but at least it's a
Alvaro Herrera wrote:
Tom Lane wrote:
I wonder whether there's any way to get the buildfarm script to report a
stack trace automatically if it finds a core file left behind in the
$PGDATA directory after running the tests. Would something like this
be adequately portable?
if [ -f
Andrew Dunstan wrote:
here's a quick untested patch for buildfarm that Stefan might like to try.
Note that not all core files are named core. On some Linux distros,
it's configured to be core.PID by default. And you can even change it
to weirder names, but I haven't seen those anywhere by
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
here's a quick untested patch for buildfarm that Stefan might like to try.
Note that not all core files are named core. On some Linux distros,
it's configured to be core.PID by default.
And on some platforms, cores don't drop in
Several of the buildfarm machines are exhibiting repeatable signal 11
crashes in what seem perfectly ordinary queries. This started about
four days ago so I suppose it's got something to do with my
operator-families patch :-( ... but I dunno what, and none of my own
machines show the failure.
17 matches
Mail list logo
