| From: | Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] doc: clarify pg_stat_lock.fastpath_exceeded scope |
| Date: | 2026-06-22 11:34:12 |
| Message-ID: | CAHza6qej7PATweXhE-Q3ihZGtWgdoNEjC==FLeaNF_4r6+PEgg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Bertrand-san,
Thanks for the review.
> Should we add a description of the consequences of not being able to
> acquire the lock in fast-path (when there are no available slots)?
> For example, we could say that this is considerably more expensive
> and may be subject to contention.
Agreed. v3 adds the following paragraph at the end of the Fast-Path
Locking subsection:
+ <para>
+ Acquiring a lock via the main lock table is considerably more
+ expensive than the fast path, and under heavy concurrent lock
+ activity can become a point of contention (observable as the
+ <literal>LockManager</literal> wait event).
+ </para>
Other parts of the patch are unchanged from v2.
v3 attached.
Regards,
Tatsuya Kawata
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-doc-add-Fast-Path-Locking-section.patch | application/octet-stream | 4.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-06-22 11:38:07 | Re: TID recycling race during nbtree index-only scans that run on a standby |
| Previous Message | Nishant Sharma | 2026-06-22 11:34:01 | Re: [PATCH] Add support for SAOP in the optimizer for partial index paths |