Re: ilist.h is not useful as-is
От | Andres Freund |
---|---|
Тема | Re: ilist.h is not useful as-is |
Дата | |
Msg-id | 20130724184824.GB10784@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: ilist.h is not useful as-is (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Andres Freund <andres@2ndquadrant.com> writes: > > The first attached patch adds slist_delete_current(), updates the > > comments addressing your points and converts the bgworker code to pass > > the iterator around (it's more efficient which might actually matter > > with a few hundred bgworkers). > > I found the added newlines in slist_foreach_modify useful, but maybe they > > should be removed again. > > > I think this should be included in 9.3 once reviewed. > > Agreed; since we have not shipped ilist.h in a release yet, the benefits > of having it behave the same in all branches should outweigh any pain > from changing this post-beta. Especially as it shouldn't break any existing working code since the old API is still there. Obviously it breaks the ABI, but ... On 2013-07-24 14:29:42 -0400, Tom Lane wrote: > > The second patch adds a regression test for background workers via > > worker_spi which I used to test slist_delete_current() addition. It's not 100% as > > it, but I thought it worthwile to post it anyway > > Hm. I'll review and commit the ilist changes, but Alvaro or somebody > should decide if such a test is sensible. I'd be a bit worried about > it in a "make installcheck" context ... I've disabled installcheck for that reason. Is there any way to override a makefile target in gnu make without a warning? If we want coverage for statically registered workers - which seems like a good idea, we need our own postgresql.conf stanza and thus a manual pg_regress invocation anyway. Which should fix that error. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: