Skip site navigation (1) Skip section navigation (2)

Re: unable to fail over to warm standby server

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Mason Hale <mason(at)onespot(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: unable to fail over to warm standby server
Date: 2010-01-30 00:07:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Actually, I think there's a tiny harmless bug in the server too. When it
> prints the error message:
> 2010-01-18 21:08:31 UTC ()FATAL:  could not restore file
> "0000000200003C82000000D8" from archive: return code 65280
> That return code is not the return code that came from the
> restore_command. Ie if you do exit(200) in the command, you won't see
> "return code 200", but you see the return value from system(). system()
> doesn't return the exit code directly, but an encoded integer that
> includes the exit code. You're supposed to call WEXITSTATUS() on it to
> get the real return code.
> That only affects the error message and is harmless otherwise, but I
> thought I'd mention it. I'll fix it, unless someone wants to argue that
> its more useful to print the raw return value of system(), because it
> might contain more information like which signal killed the process,
> that you could extract from the cryptic error code using e.g WTERMSIG()
> macro.

An "if" statement would seem to be in order, so that you can print out
either the exit code or the signal number as appropriate.


In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2010-01-30 00:18:52
Subject: Re: unable to fail over to warm standby server
Previous:From: Florian NigschDate: 2010-01-29 22:18:32
Subject: Re: BUG #5302: WIN1252 encoding causes server memory leak

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group