Re: shared-memory based stats collector - v70

From: Greg Stark <stark(at)mit(dot)edu>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: shared-memory based stats collector - v70
Date: 2022-08-08 15:53:19
Message-ID: CAM-w4HMYkM_DkYhWtUGV+qE_rrBxKOzOF0+5faozxO3vXrc9wA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm trying to wrap my head around the shared memory stats collector
infrastructure from
<20220406030008(dot)2qxipjxo776dwnqs(at)alap3(dot)anarazel(dot)de> committed in
5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.

I have one question about locking -- afaics there's nothing protecting
reading the shared memory stats. There is an lwlock protecting
concurrent updates of the shared memory stats, but that lock isn't
taken when we read the stats. Are we ok relying on atomic 64-bit reads
or is there something else going on that I'm missing?

In particular I'm looking at pgstat.c:847 in pgstat_fetch_entry()
which does this:

memcpy(stats_data,
pgstat_get_entry_data(kind, entry_ref->shared_stats),
kind_info->shared_data_len);

stats_data is the returned copy of the stats entry with all the
statistics in it. But it's copied from the shared memory location
directly using memcpy and there's no locking or change counter or
anything protecting this memcpy that I can see.

--
greg

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-08-08 15:53:41 Re: [RFC] building postgres with meson - v10
Previous Message Imseih (AWS), Sami 2022-08-08 15:51:30 Re: [BUG] Panic due to incorrect missingContrecPtr after promotion