Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> I think you should lose the "The", if nothing else. Most Postgres
>> messages I recall say "return code = xx" not "The return code ..."
> Right, that's because they are in errmessage() and not errdetail(). The
> guidelines are dif
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Yes, I had missed that difference. Next try ...
Looks sane to me.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Simon Riggs wrote:
> On Tue, 2007-12-11 at 23:31 +0100, Peter Eisentraut wrote:
> > Simon Riggs wrote:
> > > I prefer archive_command = ... for the errdetail though. The commands
> > > can be quite long so the extra words don't really add anything, plus
> > > they require translation.
> >
> > I di
On Tue, 2007-12-11 at 23:31 +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > I prefer archive_command = ... for the errdetail though. The commands
> > can be quite long so the extra words don't really add anything, plus
> > they require translation.
>
> I did like this suggestion, but then
Tom Lane wrote:
> No, you are confusing the cases "called shell was killed by a signal"
> and "called command was killed by a signal, which the shell then turned
> around and reported to us as exit > 128".
Yes, I had missed that difference. Next try ...
--
Peter Eisentraut
http://developer.post
Simon Riggs wrote:
> I prefer archive_command = ... for the errdetail though. The commands
> can be quite long so the extra words don't really add anything, plus
> they require translation.
I did like this suggestion, but then I noticed, we don't actually report the
setting of the archive_command
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 11. Dezember 2007 schrieb Tom Lane:
>> Doesn't this patch break the behavior that is documented in the comment?
>> Specifically, the case where the restore_command dies on a signal and
>> this is reported to us by the controlling shell as
Am Dienstag, 11. Dezember 2007 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Better patch.
>
> Doesn't this patch break the behavior that is documented in the comment?
> Specifically, the case where the restore_command dies on a signal and
> this is reported to us by the cont
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Better patch.
Doesn't this patch break the behavior that is documented in the comment?
Specifically, the case where the restore_command dies on a signal and
this is reported to us by the controlling shell as exitcode > 128.
We want the archiver to die
On Tue, 2007-12-11 at 17:27 +0100, Peter Eisentraut wrote:
> Am Montag, 10. Dezember 2007 schrieb Alvaro Herrera:
> > Peter Eisentraut wrote:
> > > I figured it would make sense if pgarch.c used the same mechanism that
> > > postmaster.c uses to report the various variants of regular and signal
> >
Am Montag, 10. Dezember 2007 schrieb Alvaro Herrera:
> Peter Eisentraut wrote:
> > I figured it would make sense if pgarch.c used the same mechanism that
> > postmaster.c uses to report the various variants of regular and signal
> > exits.
>
> Hmm. Getting rid of the "(PID 0)" is going to be a mes
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I figured it would make sense if pgarch.c used the same mechanism that
>> postmaster.c uses to report the various variants of regular and signal
>> exits.
> Hmm. Getting rid of the "(PID 0)" is going to be a mess enough for
>
On Mon, 2007-12-10 at 18:27 +0100, Peter Eisentraut wrote:
> Failures of archive_command calls report a confusing exit status such as:
>
> LOG: archive command "cp 'pg_xlog/0001'
> '/nonexistent/0001'" failed: return code 256
>
> The actual return code is
Peter Eisentraut wrote:
> I figured it would make sense if pgarch.c used the same mechanism that
> postmaster.c uses to report the various variants of regular and signal
> exits.
Hmm. Getting rid of the "(PID 0)" is going to be a mess enough for
translations that I think it is worth pgarch.c hav
Failures of archive_command calls report a confusing exit status such as:
LOG: archive command "cp 'pg_xlog/0001'
'/nonexistent/0001'" failed: return code 256
The actual return code is 1; it neglects to apply WEXITSTATUS().
I figured it would make sense
15 matches
Mail list logo
