FW: Possible to emulate pre-8.2 behaviour of SET CONSTRAINTS?

In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin
works always), i got the above message.

The pgsql server restarted right away, but in the meantime a significant cron
job that just hapened to be executed between SIG7 and start, failed, and so
that triggered the investigation.

Could you think of a reason for this "signal 7" caught by the pgsql server?

Memory or other HW problem maybe?

Thank you.

--
Achilleas Mantzios

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:

In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin
works always), i got the above message.

Since you have not told us what the platform is, there is no way to
guess what signal 7 means. Please look in its /usr/include/signal.h
(or more likely, some sub-file that includes) to find out the symbolic
name of the signal, and report that.

For instance, on the machine I'm on at the moment, I find this in
/usr/include/sys/signal.h:

# define _SIGEMT 7 /* EMT instruction */

but I rather doubt that's what it means on yours.

regards, tom lane

Tom Lane wrote:

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:

In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin
works always), i got the above message.

Since you have not told us what the platform is, there is no way to
guess what signal 7 means. Please look in its /usr/include/signal.h
(or more likely, some sub-file that includes) to find out the symbolic
name of the signal, and report that.

kill -l is mandated by POSIX to return the list of signal names and
numbers.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

Tom Lane wrote:

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:

In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin
works always), i got the above message.

Since you have not told us what the platform is, there is no way to
guess what signal 7 means. Please look in its /usr/include/signal.h
(or more likely, some sub-file that includes) to find out the symbolic
name of the signal, and report that.

kill -l is mandated by POSIX to return the list of signal names and
numbers.

Is there no API to return the name of signals? I am looking for
something like this on Win32 for exceptions and can't find it either.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Στις Δευτέρα 22 Ιανουάριος 2007 18:01, γράψατε:

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:

In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty
dialin works always), i got the above message.

Since you have not told us what the platform is, there is no way to
guess what signal 7 means. Please look in its /usr/include/signal.h
(or more likely, some sub-file that includes) to find out the symbolic
name of the signal, and report that.

For instance, on the machine I'm on at the moment, I find this in
/usr/include/sys/signal.h:

# define _SIGEMT 7 /* EMT instruction */

but I rather doubt that's what it means on yours.

Its a Bus error (SIGBUS). Those remote servers run on linux.

regards, tom lane

--
Achilleas Mantzios

Bruce Momjian wrote:

Is there no API to return the name of signals?

There is, but it's not portable. If someone wants to perform an
exercise in writing configure code, look for strsignal() and
sys_siglist[].

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Στις Τρίτη 23 Ιανουάριος 2007 16:25, γράψατε:

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:

Since you have not told us what the platform is, there is no way to
guess what signal 7 means.

Its a Bus error (SIGBUS). Those remote servers run on linux.

Hm, pretty indeterminate then --- could be flaky hardware, or an
invalid storage access caused either by a software bug or corrupted
data.

My advice would be (1) update to something newer than 7.4.2, and
(2) run some hardware tests such as memtest86.

We ship the new machines with 7.4.15 installed.
Unfortunately the ones already at production are not easy
to reach by any means (in the 7 seas, unreliable SAT coms,
mgetty not always work), so not only we cannot boot
memtest86, but many times we can't even get a shell to do basic admin work.

oh and the lines are unreliable 64kbps ISDN, 9600bps or even 2400bps!!,

Weird setup for most of you, but it proves postgresql robustness running
50 such servers with almost zero administration/problems.

regards, tom lane

--
Achilleas Mantzios

Peter Eisentraut wrote:

Bruce Momjian wrote:

Is there no API to return the name of signals?

There is, but it's not portable. If someone wants to perform an
exercise in writing configure code, look for strsignal() and
sys_siglist[].

Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we only have a three-argument function to log.
Attached and applied.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

New log output will look like:

LOG: server process (PID 29304) was terminated by signal: Bus error (10)

---------------------------------------------------------------------------

Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian wrote:

Is there no API to return the name of signals?

There is, but it's not portable. If someone wants to perform an
exercise in writing configure code, look for strsignal() and
sys_siglist[].

Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we only have a three-argument function to log.
Attached and applied.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

[ text/x-diff is unsupported, treating like TEXT/PLAIN ]

Index: configure
===================================================================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.530
diff -c -c -r1.530 configure
*** configure	18 Jan 2007 14:07:30 -0000	1.530
--- configure	28 Jan 2007 01:02:58 -0000
***************
*** 15600,15605 ****
--- 15600,15667 ----
rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext

+ echo "$as_me:$LINENO: checking for sys_siglist" >&5
+ echo $ECHO_N "checking for sys_siglist... $ECHO_C" >&6
+ if test "${pgac_cv_var_sys_siglist+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ /* confdefs.h.  */
+ _ACEOF
+ cat confdefs.h >>conftest.$ac_ext
+ cat >>conftest.$ac_ext <<_ACEOF
+ /* end confdefs.h.  */
+ #include <signal.h>
+ int
+ main ()
+ {
+ extern char *sys_siglist[]; (void)sys_siglist[0];
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext conftest$ac_exeext
+ if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+   (eval $ac_link) 2>conftest.er1
+   ac_status=$?
+   grep -v '^ *+' conftest.er1 >conftest.err
+   rm -f conftest.er1
+   cat conftest.err >&5
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } &&
+ 	 { ac_try='test -z "$ac_c_werror_flag"
+ 			 || test ! -s conftest.err'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; } &&
+ 	 { ac_try='test -s conftest$ac_exeext'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; }; then
+   pgac_cv_var_sys_siglist=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ sed 's/^/| /' conftest.$ac_ext >&5
+ 
+ pgac_cv_var_sys_siglist=no
+ fi
+ rm -f conftest.err conftest.$ac_objext \
+       conftest$ac_exeext conftest.$ac_ext
+ fi
+ echo "$as_me:$LINENO: result: $pgac_cv_var_sys_siglist" >&5
+ echo "${ECHO_T}$pgac_cv_var_sys_siglist" >&6
+ if test x"$pgac_cv_var_sys_siglist" = x"yes"; then
+ 
+ cat >>confdefs.h <<\_ACEOF
+ #define HAVE_SYS_SIGLIST 1
+ _ACEOF
+ 
+ fi
+ 
echo "$as_me:$LINENO: checking for syslog" >&5
echo $ECHO_N "checking for syslog... $ECHO_C" >&6
if test "${ac_cv_func_syslog+set}" = set; then
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.497
diff -c -c -r1.497 configure.in
*** configure.in	18 Jan 2007 14:07:31 -0000	1.497
--- configure.in	28 Jan 2007 01:03:00 -0000
***************
*** 1059,1064 ****
--- 1059,1073 ----
AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)])

+ AC_CACHE_CHECK([for sys_siglist], pgac_cv_var_sys_siglist,
+ [AC_TRY_LINK([#include <signal.h>],
+   [extern char *sys_siglist[]; (void)sys_siglist[0];],
+   [pgac_cv_var_sys_siglist=yes],
+   [pgac_cv_var_sys_siglist=no])])
+ if test x"$pgac_cv_var_sys_siglist" = x"yes"; then
+   AC_DEFINE(HAVE_SYS_SIGLIST, 1, [Define to 1 if you have the global variable 'char *sys_siglist[]'.])
+ fi
+ 
AC_CHECK_FUNC(syslog,
[AC_CHECK_HEADER(syslog.h,
[AC_DEFINE(HAVE_SYSLOG, 1, [Define to 1 if you have the syslog interface.])])])
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.512
diff -c -c -r1.512 postmaster.c
*** src/backend/postmaster/postmaster.c	23 Jan 2007 03:28:49 -0000	1.512
--- src/backend/postmaster/postmaster.c	28 Jan 2007 01:03:02 -0000
***************
*** 2421,2443 ****
(errmsg("%s (PID %d) exited with exit code %d",
procname, pid, WEXITSTATUS(exitstatus))));
else if (WIFSIGNALED(exitstatus))
! #ifndef WIN32
ereport(lev,

/*------
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by signal %d",
! procname, pid, WTERMSIG(exitstatus))));
#else
ereport(lev,

/*------
translator: %s is a noun phrase describing a child process, such as
"server process" */
! 				(errmsg("%s (PID %d) was terminated by exception %X",
! 						procname, pid, WTERMSIG(exitstatus)),
! 				 errhint("See /include/ntstatus.h for a description of the hex value.")));
#endif
else
ereport(lev,
--- 2421,2453 ----
(errmsg("%s (PID %d) exited with exit code %d",
procname, pid, WEXITSTATUS(exitstatus))));
else if (WIFSIGNALED(exitstatus))
! #if defined(WIN32)
ereport(lev,

/*------
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by exception %X",
! procname, pid, WTERMSIG(exitstatus)),
! errhint("See C include file \"ntstatus.h\" for a description of the hex value.")));
! #elif defined(HAVE_SYS_SIGLIST)
! ereport(lev,
!
! /*------
! translator: %s is a noun phrase describing a child process, such as
! "server process" */
! (errmsg("%s (PID %d) was terminated by signal: %s (%d)",
! procname, pid, WTERMSIG(exitstatus) < NSIG ?
! sys_siglist[WTERMSIG(exitstatus)] : "unknown signal",
! WTERMSIG(exitstatus))));
#else
ereport(lev,

/*------
translator: %s is a noun phrase describing a child process, such as
"server process" */
! 				(errmsg("%s (PID %d) was terminated by signal %d",
! 						procname, pid, WTERMSIG(exitstatus))));
#endif
else
ereport(lev,
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql/src/include/pg_config.h.in,v
retrieving revision 1.108
diff -c -c -r1.108 pg_config.h.in
*** src/include/pg_config.h.in	2 Jan 2007 21:25:50 -0000	1.108
--- src/include/pg_config.h.in	28 Jan 2007 01:03:03 -0000
***************
*** 478,483 ****
--- 478,486 ----
/* Define to 1 if you have the <sys/shm.h> header file. */
#undef HAVE_SYS_SHM_H

+ /* Define to 1 if you have the global variable 'char *sys_siglist[]'. */
+ #undef HAVE_SYS_SIGLIST
+ 
/* Define to 1 if you have the <sys/socket.h> header file. */
#undef HAVE_SYS_SOCKET_H

Index: src/port/exec.c
===================================================================
RCS file: /cvsroot/pgsql/src/port/exec.c,v
retrieving revision 1.48
diff -c -c -r1.48 exec.c
*** src/port/exec.c	23 Jan 2007 03:31:33 -0000	1.48
--- src/port/exec.c	28 Jan 2007 01:03:05 -0000
***************
*** 582,592 ****
log_error(_("child process exited with exit code %d"),
WEXITSTATUS(exitstatus));
else if (WIFSIGNALED(exitstatus))
! #ifndef WIN32
! 		log_error(_("child process was terminated by signal %d"),
WTERMSIG(exitstatus));
#else
! 		log_error(_("child process was terminated by exception %X\nSee /include/ntstatus.h for a description of the hex value."),
WTERMSIG(exitstatus));
#endif
else
--- 582,596 ----
log_error(_("child process exited with exit code %d"),
WEXITSTATUS(exitstatus));
else if (WIFSIGNALED(exitstatus))
! #if defined(WIN32)
! 		log_error(_("child process was terminated by exception %X\nSee C include file \"ntstatus.h\" for a description of the hex value."),
WTERMSIG(exitstatus));
+ #elif defined(HAVE_SYS_SIGLIST)
+ 		log_error(_("child process was terminated by signal: %s"),
+ 					WTERMSIG(exitstatus) < NSIG ?
+ 					sys_siglist[WTERMSIG(exitstatus)] : "unknown signal");
#else
! 		log_error(_("child process was terminated by signal %d"),
WTERMSIG(exitstatus));
#endif
else

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we only have a three-argument function to log.
Attached and applied.

This patch has broken much of the buildfarm.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we only have a three-argument function to log.
Attached and applied.

This patch has broken much of the buildfarm.

I think it is because I didn't have #include <signal.h> in exec.c. Added.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

This patch has broken much of the buildfarm.

I think it is because I didn't have #include <signal.h> in exec.c. Added.

Doesn't seem to have helped ...

regards, tom lane

Bruce Momjian wrote:

New log output will look like:

LOG: server process (PID 29304) was terminated by signal: Bus
error (10)

The colon doesn't make sense to me.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Bruce Momjian wrote:

New log output will look like:

LOG: server process (PID 29304) was terminated by signal: Bus
error (10)

The colon doesn't make sense to me.

OK, it seemed strange to say "signal Bus error (10)" because of the
capitalization, but I will remove the colon.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

This patch has broken much of the buildfarm.

I think it is because I didn't have #include <signal.h> in exec.c. Added.

Doesn't seem to have helped ...

It did for some, and using the built-in macro fixed the rest.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian wrote:

New log output will look like:

LOG: server process (PID 29304) was terminated by signal: Bus
error (10)

The colon doesn't make sense to me.

OK, it seemed strange to say "signal Bus error (10)" because of the
capitalization, but I will remove the colon.

To make the grammar match better it might be safer to put the text
inside the parentheses and the number into the sentence. That would
also work better for translation.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian wrote:

New log output will look like:

LOG: server process (PID 29304) was terminated by signal: Bus
error (10)

The colon doesn't make sense to me.

OK, it seemed strange to say "signal Bus error (10)" because of the
capitalization, but I will remove the colon.

To make the grammar match better it might be safer to put the text
inside the parentheses and the number into the sentence. That would
also work better for translation.

OK. I will also add the number to the exec.c case by snprint into a
local string in that block, and passing that to log_error.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Peter Eisentraut wrote:

To make the grammar match better it might be safer to put the text
inside the parentheses and the number into the sentence. That would
also work better for translation.

OK. I will also add the number to the exec.c case by snprint into a
local string in that block, and passing that to log_error.

I don't like that because it parenthesizes the most important part of
the message, which is a style-guideline violation at least in spirit.
How about

... terminated by signal 10: Bus error

regards, tom lane

Tom Lane wrote:

I don't like that because it parenthesizes the most important part of
the message, which is a style-guideline violation at least in spirit.
How about

... terminated by signal 10: Bus error

I like that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/