| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Alex Friedman <alexf01(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Doc: clarify possibility of ephemeral discrepancies between state and wait_event in pg_stat_activity |
| Date: | 2025-02-27 16:02:14 |
| Message-ID: | CAA5RZ0sRyfuKbzFpLLoHp0=WnerXwyvZz+-fvFdMKyQqRZpQug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> It's also worth noting that pg_locks already has a full paragraph explaining
> inconsistencies, so in my opinion it's worth it at least mentioning something
> similar here for pg_stat_activity.
yes, that is a different consistency from the one I was referring to with
regards to a join between pg_locks and pg_stat_activity, but I do
agree that it is worth calling out the expectation for pg_stat_activity.
> Thanks for the feedback, I've attached a v2 patch which has wording that's a bit
> more generic.
A few comments. I don't like the use of "lightweight" here as it is
usually referring
to LWLocks ( lightweight locks ), which can cause confusion. Also,if
we are going
to mention specific examples, I think we will need to explain further what the
discrepancy will look like. What about we do something much more
simplified, such
as the below:
"""
To keep the reporting overhead low, the system does not attempt to synchronize
activity data for a backend. As a result, ephemeral discrepancies may
exist between
the view’s columns.
"""
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-02-27 16:07:14 | Re: new commitfest transition guidance |
| Previous Message | Tom Lane | 2025-02-27 16:00:22 | Re: pgbench client-side performance issue on large scripts |