On Thu, May 22, 2014 at 9:51 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> Suppose a user backend starts a background worker for some purpose;
> the background worker dies with an error. The infrastructure we have
> today is sufficient for the user backend to discover that the worker
> backend has died, but not why. There might be an error in the server
> log, but the error information won't be transmitted back to the user
> backend in any way. I think it would be nice to fix that. I also
> think it would be nice to be able to relay not only errors, but also
> messages logged via ereport() or elog() at lower log levels (WARNING,
> NOTICE, INFO, DEBUG).
>
> The design I have in mind is to teach elog.c how to write such
> messages to a shm_mq. This is in fact one of the major use cases I
> had in mind when I designed the shm_mq infrastructure, because it
> seems to me that almost anything we want to do in parallel is likely
> to want to do this. Even aside from parallelism, it's not too hard to
> imagine wanting to use background workers to launch a job in the
> background and then come back later and see what happened. If there
> was an error, you're going to want go know specifically what went
> wrong, not just that something went wrong.
>
> The main thing I'm not sure about is how to format the message that we
> write to the shm_mq. One option is to try to use the good old FEBE
> protocol. This doesn't look entirely straightforward, because
> send_message_to_frontend() assembles the message using pq_sendbyte()
> and pq_sendstring(), and then sends it out to the client using
> pq_endmessage() and pq_flush(). This infrastructure assumes that the
> connection to the frontend is a socket. It doesn't seem impossible to
> kludge that infrastructure to be able to send to either a socket or a
> shm_mq, but I'm not sure whether it's a good idea.
I think it will be better to keep assembling part of message similar to
current and then have different way of communicating to backend.
This will make rethrowing of message to client simpler.
Already we have mechanism for reporting to client and server
(send_message_to_server_log()/send_message_to_frontend()), so
devising a similar way for communicating with backend seems to be
a plausible way.