Joseph Brenner <doomvox@xxxxxxxxx> writes:
> Looking back on the order of events, I think it went like this:
> [ careful postmortem ]
Thanks for following up!
> So yeah, some better messaging when PAGER is mangled wouldn't hurt, if
> that's possible. Falling back to "pager off" would make sense to me.
Agreed. One thing that would be very simple is to treat an empty PAGER
value the same as "unset". Detecting whether a nonempty value is behaving
sanely seems a great deal harder; depending on what pager you're using
and how you stop it, nonzero exit codes from the called process might
be normal. I think it might be practical to issue a warning if we get
an exit code of 126 or 127, though. We have a comment in archive-command
invocation:
* Per the Single Unix Spec, shells report exit status > 128 when a called
* command died on a signal. Also, 126 and 127 are used to report
* problems such as an unfindable command; treat those as fatal errors
* too.
The relevant text in POSIX is
If a command is not found, the exit status shall be 127. If the
command name is found, but it is not an executable utility, the
exit status shall be 126. Applications that invoke utilities
without using the shell should use these exit status values to
report similar errors.
I don't believe we want to complain about exit on a signal, because
SIGTERM or SIGINT is a typical exit in some pager setups. But these
two codes strongly suggest something broken about your PAGER value.
So I propose
(1) ignore PAGER if it's an empty string
(2) if pclose returns exit code 126 or 127, report that the PAGER
command didn't work. I'm not sure how complex that is, because IIRC
the pclose is at some remove from the popen call, but if it's not
unreasonably hairy we should do it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
