Re: shared-memory based stats collector
От | Tomas Vondra |
---|---|
Тема | Re: shared-memory based stats collector |
Дата | |
Msg-id | 854d6d91-f2f3-e391-f0fc-064db51b391e@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: shared-memory based stats collector (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: shared-memory based stats collector
|
Список | pgsql-hackers |
On 11/29/18 1:18 PM, Alvaro Herrera wrote: > On 2018-Nov-28, Tomas Vondra wrote: > >>> v10-0004-Shared-memory-based-stats-collector.patch >>> updated not to touch guc. >>> v10-0005-Remove-the-GUC-stats_temp_directory.patch >>> collected all guc-related changes. >>> updated not to break other programs. >>> v10-0006-Split-out-backend-status-monitor-part-from-pgstat.patch >>> basebackup.c requires both bestats.h and pgstat.h >>> v10-0007-Documentation-update.patch >>> small change related to 0005. >> >> I need to do a more thorough review of part 0006, but these patches >> seems quite fine to me. I'd however merge 0007 into the other relevant >> parts (it seems like a mix of docs changes for 0004, 0005 and 0006). > > Looking at 0001 - 0003 it seems OK to keep each as separate commits, but > I suggest to have 0004+0006 be a single commit, mostly because > introducing a bunch of "new" code in 0004 and then moving it over to > bestatus.c in 0006 makes "git blame" doubly painful. And I think > committing 0005 and not 0007 makes the documentation temporarily buggy, > so I see no reason to think of this as two commits, one being 0004+0006 > and the other 0005+0007. And even those could conceivably be pushed > together instead of as a single patch. (But be sure to push very early > in your work day, to have plenty of time to deal with any resulting > buildfarm problems.) > Kyotaro-san, do you agree with committing the patch the way Alvaro proposed? That is, 0001-0003 as separate commits, and 0004+0006 and 0005+0007 together. The plan seems reasonable to me. FWIW I see cputube reports some build failures on Windows: https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.26736#L3135 If I understand it correctly, it complains about this line in postmaster.c: extern pgsocket pgStatSock; which seems to only affect EXEC_BACKEND (including Win32). ISTM we should get rid of all pgStatSock references, per the attached fix. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: