Re: [ADMIN] server process (PID xxx) was

That sounds like a plan - will give it a go. Thanks!

simon

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Monday, January 22, 2007 3:37 AM
To: Simon Kinsella
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: [SQL] Possible to emulate pre-8.2 behaviour of SET CONSTRAINTS?

"Simon Kinsella" <simon(at)bluefiresystems(dot)co(dot)uk> writes:
> My system currently runs on PostgreSQL 8.1 and makes use of the old
> behaviour of SET CONSTRAINTS, namely that the command is applied to
> all constraints that match the specified name.

Unfortunately that was pretty far away from what the SQL spec says :-(

> This makes it very easy to write
> a general-case function that can change the DEFERRED mode on a given
> constraint that is present in several similar schemas (sounds odd
> maybe but it works very well in my case!).

I think you could do it fairly easily still, eg

for rec in select nspname from pg_namespace n join pg_constraint c
on n.oid = c.connamespace where conname = $1 loop
execute 'set constraints ' || quote_ident(rec.nspname) || '.' ||
quote_ident($1) || ' immediate';
end loop;

Exceedingly untested, but something close to this seems like it'd solve your
problem.

regards, tom lane

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(at)matrix(dot)gatewaynet(dot)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(at)matrix(dot)gatewaynet(dot)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(at)matrix(dot)gatewaynet(dot)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(at)momjian(dot)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(at)matrix(dot)gatewaynet(dot)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(at)matrix(dot)gatewaynet(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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/

Peter Eisentraut wrote:
> 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.

OK, but you guys added back that colon you didn't like. :-)

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

On Sun, Jan 28, 2007 at 05:02:24PM -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > 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.
>
> OK, but you guys added back that colon you didn't like. :-)

Placement is crucial. Compare

terminated by signal 10: Bus error <-- proposed version
terminated by signal: 10 Bus error <-- older version

Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

Peter Eisentraut wrote:
> 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.

Patch attached and applied; new message from exec.c and postmaster.c:

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

Nice!

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

David Fetter wrote:
> On Sun, Jan 28, 2007 at 05:02:24PM -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > 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.
> >
> > OK, but you guys added back that colon you didn't like. :-)
>
> Placement is crucial. Compare
>
> terminated by signal 10: Bus error <-- proposed version
> terminated by signal: 10 Bus error <-- older version

FYI, that was not the old version.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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