Re: shared-memory based stats collector

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, andres(at)anarazel(dot)de, ah(at)cybertec(dot)at, magnus(at)hagander(dot)net, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared-memory based stats collector
Date: 2019-01-01 17:39:12
Views: Raw Message | Whole Thread | Download mbox
Lists: 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:

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.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
pgstatsock-fix.patch text/x-patch 1.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-01-01 17:39:17 Re: explain plans with information about (modified) gucs
Previous Message Tomas Vondra 2019-01-01 17:37:58 Re: FETCH FIRST clause WITH TIES option