On 22/05/14 06:21, Robert Haas wrote:
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. Alternatively, we could devise some other message format specific to this problem; it would probably look a lot like an ErrorData protocol message, but maybe that's doesn't really matter. Any thoughts?
I played with this a bit already and even have some (very much hacked up) prototype based on ErrorData as it seemed better solution than using sockets. Obviously some of the ErrorData fields don't really have meaning during transport (send_to_client for example) as those must be set based on the connection options and I didn't get to making this nicer yet.
Another thing to think about is that, most likely, many users of the background worker facility will want to respond to a relayed error by rethrowing it. That means that whatever format we use to send the error from one process to the other has to be able to be decoded by the receiving process. That process will probably want to do something like add add a bit more to the context (e.g. "in background worker PID %d") and throw the resulting error preserving the rest of the original fields. I'm not sure exactly what make sense here, but the point is that ideally the message format should be something that the receiver can rethrow, possibly after tweaking it a bit.
This is one advantage of using ErrorData or ErrorData-like structure based messaging, rethrowing is simpler, but I guess if we really needed we could provide some conversion api.
One side effect of the rethrowing that maybe deserves a bit of thought is that we are going to log the same error from both bgworker and backend if we rethrow it.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
