On Tue, Sep 9, 2014 at 12:33 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
> I am not sure if what Andres proposed is the right solution, but I do agree
> here that the hook definitely isn't.
Well, that doesn't get me very far. Andres never responded to my
previous comments about why I did it that way, and you're not
proposing a clear alternative that I can either implement or comment
on.
> I am also not sure that I like the pq_redirect_to_shm_mq being directly
> exposed for use in bgworker, what I would like is to have elog interface to
> which you tell that you want errors sent to shm_mq handle and that one would
> then do the necessary calls (It's basically same principle but for the sake
> of cleanliness/correctness I think it should be elog and not pq from the
> point of bgworker).
I think that's completely wrong. As the patch series demonstrates,
it's not limited to propagating ErrorResponse and NoticeResponse. It
can also propagate NotifyResponse and RowDescription and DataRow and
anything else that comes along. We are not just propagating errors;
we are propagating all protocol messages of whatever type. So tying
it to elog specifically is not right.
> So the interface needs work.
>
> I do agree that we don't need two way communication over this channel, I
> think the dsm_mq can be used directly quite well for generic usecase.
I'm glad you agree, but that leaves me baffled as to what's wrong with
the hook approach. There's no crying need for extensibility in this
code; it's barely changed in a very long time, and I know of no other
need which might soon require changing it again. The hook is very
lightweight and shouldn't materially affect performance when it's not
used, as a more complex approach might.
> Otherwise I like the patch, and I am glad you also made the GUC save/restore
> infrastructure.
Cool.
> Please don't forget to add this to next commitfest.
OK, done. But it would be awfully nice if we could actually make some
progress on hammering out a design everyone can live with here.
Letting it sit for another 5 weeks is not going to help anything, and
it will hold up getting any more stuff after this done in time for
9.5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company