pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PG Doc comments form <noreply@postgresql.org>
To: pgsql-docs@lists.postgresql.org
Cc: sameer.kasi200x@gmail.com
Subject: Misleading description for IPC wait events in PostgreSQL documentation
Date: Thu, 04 May 2023 18:00:22 +0000
Message-ID: <168322322228.395345.6400904841473089995@wrigleys.postgresql.org> (raw)

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/15/monitoring-stats.html
Description:

While preparing for my presentation on PostgreSQL Wait Events at PgConf
India, I was trying to understand *IPC:XactGroupUpdate* in more detail.
PostgreSQL documentation [1] mentions:

> A process is waiting for the group leader to update the transaction status
at the end of a _parallel operation_.

I was looking at `TransactionGroupUpdateXidStatus` in PostgreSQL code
(`clog.c`)
Line `481` [2] sets this wait event.

And after reading the code - my understanding is it does not necessarily
need to be a "_parallel operation_". Or maybe I am just misinterpreting
"parallel operation" in this context. But it is possible for other users to
confuse it with the parallel query feature.

**My understanding is**
In order to avoid `XactSLRULock` being passed between backends, backends
waiting for it will add themselves to the queue [3]. The first backend in
the queue (also the leader) will be the only one to acquire `XactSLRULock`
and update the XID status for all those pids which are in the queue. This
wait event `IPC:XactGroupUpdate` is observed in other backened processes in
queue who are waiting for the group leader to update the XID status.

I recommend making a change to PostgreSQL docs to clearly indicate what this
wait event means:

> When concurrent processes are trying to update transaction status in the
same page of commit logs, a group leader is assigned to perform the update
and other processes wanting to perform the update wait on this IPC wait
event.

OR

> When multiple backend processes wait on a group leader to update their
transaction status, so that PostgreSQL can avoid passing around the LwLock
`XactSLRULock` between multiple backend processes. 


A similar change should be done for `ProcArrayGroupUpdate` to indicate that
the wait event is a result of concurrent backend processes trying to clear
the transaction id (instead of saying "parallel operation").

Thoughts?



[1]
https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-IPC-TABLE

[2]
https://github.com/postgres/postgres/blob/master/src/backend/access/transam/clog.c#L481

[3]
https://github.com/postgres/postgres/blob/master/src/backend/access/transam/clog.c#L399


Thanks,
Sameer
DB Specialist, 
Amazon Web Services


view thread (2+ messages)

Message-ID: <168322322228.395345.6400904841473089995@wrigleys.postgresql.org>
Permalink:  ../168322322228.395345.6400904841473089995@wrigleys.postgresql.org/
Also on:    postgresql.org/message-id/168322322228.395345.6400904841473089995@wrigleys.postgresql.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-docs@postgresql.org
  Cc: noreply@postgresql.org, pgsql-docs@lists.postgresql.org, sameer.kasi200x@gmail.com
  Subject: Re: Misleading description for IPC wait events in PostgreSQL documentation
  In-Reply-To: <168322322228.395345.6400904841473089995@wrigleys.postgresql.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox