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

Re: unable to fail over to warm standby server

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-02-09 19:47:23
Message-ID: 4B71BBCB.8070302@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
>>> 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.
> 
> Yes.  Please see the existing code in the postmaster that prints
> subprocess exit codes, and duplicate it (or perhaps refactor so you can
> avoid code duplication; though translatability of messages might limit
> what you can do there).

Here's what I came up with. Translatability indeed makes it pretty hard,
I ended up copy-pasting.

BTW, I don't think I'm going to bother or risk back-patching this. It
was harmless, and for forensic purposes all the information was there in
the old message too, just in a cryptic format. And the new messages
would need translating too.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Attachment: fix-recovery_command-fail-msg-1.patch
Description: text/x-diff (4.4 KB)

In response to

Responses

pgsql-bugs by date

Next:From: Jerry GamacheDate: 2010-02-09 21:55:32
Subject: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze
Previous:From: Russell SmithDate: 2010-02-09 07:31:11
Subject: Re: BUG #5319: recursion in the triggers

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