Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.
От
Andres Freund
Тема
Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks
for extensions are allocated.
Дата
Msg-id
20161114203259.fw3b3cmb67k2zl4z@alap3.anarazel.de
Ответ на
Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks
for extensions are allocated. (Andres Freund)
Список
Дерево обсуждения
Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks
for extensions are allocated. Alvaro Herrera <alvherre@2ndquadrant.com>
On 2016-11-14 12:14:10 -0800, Andres Freund wrote: > On 2016-11-12 11:42:12 -0500, Tom Lane wrote: > > Andres Freund writes: > > > On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > > >> which is a rather blatant waste of cycles. I would suggest an explicit > > >> do-nothing installcheck rule rather than the hack you came up with here. > > > > > I had that at first, but that generates a warning about overwriting the > > > makefile target - which afaics cannot be fixed. > > > > Hm. What about inventing an additional macro NO_INSTALLCHECK that > > prevents pgxs.mk from generating an installcheck rule? It's not > > like we don't have similar issues elsewhere, eg contrib/sepgsql. > > Well, that one seems a bit different. Seems easy enough to do. Do we > want to make that macro that prevents installcheck from being defined, > or one that forces it to be empty? The former has the disadvantage that > one has to be careful to define a target, to avoid breaking recursion > from the upper levels. Oh, that disadvantage doesn't actually exist, because installcheck is a .PHONY target... I've for now not added a variant that prevents plain 'make check' from doing anything. I guess it could be useful when a contrib module wants to run tests via something else than pg_regress? Patch attached. Andres
В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата:
От: Alvaro Herrera
Дата: