Re: pg_background (and more parallelism infrastructure patches)
От | Petr Jelinek |
---|---|
Тема | Re: pg_background (and more parallelism infrastructure patches) |
Дата | |
Msg-id | 540F3679.8090907@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: pg_background (and more parallelism infrastructure patches) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_background (and more parallelism infrastructure patches)
|
Список | pgsql-hackers |
On 09/09/14 18:49, Robert Haas wrote: > On Tue, Sep 9, 2014 at 12:33 PM, Petr Jelinek <petr@2ndquadrant.com> wrote: >> 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. > Oh in that case, I think what Andres proposed is actually quite good. I know the hook works fine it just seems like using somewhat hackish solution to save 20 lines of code. The reason why I am not proposing anything better is that my solution when I did prototyping in this area was to just check if my pq_dsm_mq handle is set or not and call the appropriate function from the wrapper based on that which does not seem like big improvement over the hook approach... Anything better/more flexible that I could come up with is basically same idea what Andres already wrote. >> 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. > Yeah I said that just as formality, I wrote the response now and not in 5 weeks exactly for this reason, I am all for discussing this now and I think it's important to hammer this infrastructure out sooner rather than later. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: