exit status 26

Dan Moschuk <dan@freebsd.org> writes:

Can someone tell me what a postmaster process exiting with status = 26
means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
records to trigger this.

That means it got a signal 26. Since you didn't mention what platform
you are on, I'm not going to guess what signal that actually is on
your Unix. How about you look in /usr/include/signal.h and/or
/usr/include/sys/signal.h and tell us?

regards, tom lane

| > Can someone tell me what a postmaster process exiting with status = 26
| > means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
| > records to trigger this.
|
| That means it got a signal 26. Since you didn't mention what platform
| you are on, I'm not going to guess what signal that actually is on
| your Unix. How about you look in /usr/include/signal.h and/or
| /usr/include/sys/signal.h and tell us?

Oh, sorry, for some reason I thought status = exit code.

Signal 26 on FreeBSD is SIGVTARLM.

--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde

Dan Moschuk <dan@freebsd.org> writes:

| > Can someone tell me what a postmaster process exiting with status = 26
| > means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
| > records to trigger this.
|
| That means it got a signal 26.

Oh, sorry, for some reason I thought status = exit code.

Postgres doesn't use exit codes higher than 2, so I'm supposing that the
reported code must be a signal code.

Signal 26 on FreeBSD is SIGVTARLM.

We don't ever set a virtual timer alarm, either. Is it possible that
you are running the postmaster with a ulimit-style limit on total
process runtime?

regards, tom lane

| > Signal 26 on FreeBSD is SIGVTARLM.
|
| We don't ever set a virtual timer alarm, either. Is it possible that
| you are running the postmaster with a ulimit-style limit on total
| process runtime?

No, I've tested this and postmaster is being started in an unlimited
enviornment.

The code that delivers the actual signal looks like this:

if (CLKF_USERMODE(frame) &&
timevalisset(&pstats->p_timer[ITIMER_VIRTUAL].it_value) &&
itimerdecr(&pstats->p_timer[ITIMER_VIRTUAL], tick) == 0)
psignal(p, SIGVTALRM);

So it is getting a virtual timer from somewhere. A grep of the backend
directory revealed no setitimer() occurances, so I can confirm that it
isn't postmaster doing it. And if the shells environment is unlimited,
which doesn't leave very many culprits left. :/

--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde

Dan Moschuk <dan@freebsd.org> writes:

So it is getting a virtual timer from somewhere. A grep of the backend
directory revealed no setitimer() occurances, so I can confirm that it
isn't postmaster doing it. And if the shells environment is unlimited,
which doesn't leave very many culprits left. :/

Yes. It would be good to question my assumption that the exit code
is a signal --- I can't see what else it could be, but can you run
the backend with a breakpoint set at exit(), and get a backtrace?

regards, tom lane

| > So it is getting a virtual timer from somewhere. A grep of the backend
| > directory revealed no setitimer() occurances, so I can confirm that it
| > isn't postmaster doing it. And if the shells environment is unlimited,
| > which doesn't leave very many culprits left. :/
|
| Yes. It would be good to question my assumption that the exit code
| is a signal --- I can't see what else it could be, but can you run
| the backend with a breakpoint set at exit(), and get a backtrace?

Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce
this problem any longer. :/

If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
to try and track this down further.

-Dan
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde

Dan Moschuk <dan@freebsd.org> writes:

| > So it is getting a virtual timer from somewhere. A grep of the backend
| > directory revealed no setitimer() occurances, so I can confirm that it
| > isn't postmaster doing it. And if the shells environment is unlimited,
| > which doesn't leave very many culprits left. :/
|
| Yes. It would be good to question my assumption that the exit code
| is a signal --- I can't see what else it could be, but can you run
| the backend with a breakpoint set at exit(), and get a backtrace?

Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce
this problem any longer. :/

If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
to try and track this down further.

I know we've got plenty of FreeBSD people on this list; surely someone
can lend you an account on a 4.1 machine. I changed the Subject: line
just to get the right peoples' attention ...

regards, tom lane

On Fri, Jan 12, 2001 at 03:49:36PM -0500, Tom Lane wrote:

If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
to try and track this down further.

I know we've got plenty of FreeBSD people on this list; surely someone
can lend you an account on a 4.1 machine. I changed the Subject: line
just to get the right peoples' attention ...

i have a 4.1-STABLE circa Sep-12-2000

--
[ Jim Mercer jim@pneumonoultramicroscopicsilicovolcanoconiosis.ca ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ aka jim@reptiles.org +1 416 410-5633 ]

* Tom Lane <tgl@sss.pgh.pa.us> [010112 12:54] wrote:

Dan Moschuk <dan@freebsd.org> writes:

| > So it is getting a virtual timer from somewhere. A grep of the backend
| > directory revealed no setitimer() occurances, so I can confirm that it
| > isn't postmaster doing it. And if the shells environment is unlimited,
| > which doesn't leave very many culprits left. :/
|
| Yes. It would be good to question my assumption that the exit code
| is a signal --- I can't see what else it could be, but can you run
| the backend with a breakpoint set at exit(), and get a backtrace?

Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce
this problem any longer. :/

If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
to try and track this down further.

I know we've got plenty of FreeBSD people on this list; surely someone
can lend you an account on a 4.1 machine. I changed the Subject: line
just to get the right peoples' attention ...

If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see
the point of you trying to track down a bad interaction between the
host OS and Postgresql for an older release.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

| > I know we've got plenty of FreeBSD people on this list; surely someone
| > can lend you an account on a 4.1 machine. I changed the Subject: line
| > just to get the right peoples' attention ...
|
| If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see
| the point of you trying to track down a bad interaction between the
| host OS and Postgresql for an older release.

Because I'd like to verify that it was in fact a bug with 4.1 and not
something else.

--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde

Dan Moschuk <dan@freebsd.org> writes:

| If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see
| the point of you trying to track down a bad interaction between the
| host OS and Postgresql for an older release.

Because I'd like to verify that it was in fact a bug with 4.1 and not
something else.

Even if it is a since-fixed 4.1 bug, there are doubtless still people
out there running 4.1, to say nothing of other *BSD and less-closely-
related Unixen that may have the same or similar bug. If Dan can
isolate the problem and identify a reasonable workaround, we should
probably put the workaround into Postgres.

regards, tom lane