| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Use more strlcpy() in two-phase transaction code |
| Date: | 2026-07-28 23:55:27 |
| Message-ID: | E1wordv-00000000jAh-3jwy@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Use more strlcpy() in two-phase transaction code
This commit replaces two calls of strcpy() and one call of strncpy() to
use strlcpy(), which are patterns that static analyzers (mostly LLMs, it
seems) have been complaining regarding buffer overflow risks.
The existing calls are safe, here are more details for each one of them:
- MarkAsPreparingGuts()'s strcpy() was guarded by MarkAsPreparing().
- PrepareRedoAdd()'s strcpy() is safe because the record-level CRC check
prevents corrupted data from reaching it unless intentionally
crafted. The replay code also assumes that the GID is within the allowed
bounds, as WAL records are trusted.
- Similarly, ParsePrepareRecord() stores its GID in a buffer bounded by
GIDSIZE while trusting the length provided by the record.
As a result, these changes are purely cosmetic. They adopt a more
defensive coding style and should also silence some of the static
analysis reports received recently.
Author: Matt Suiche <matt(at)tolmo(dot)com>
Discussion: https://postgr.es/m/CAGf6Lfx2kbQfcEnCi99V2i65JSWD6ij_E29F+UkY=TyMUyeG6A@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/dd50eb9145eead17ebd62db2e43a6de7c53102c0
Modified Files
--------------
src/backend/access/rmgrdesc/xactdesc.c | 2 +-
src/backend/access/transam/twophase.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-07-29 04:23:18 | pgsql: Avoid accumulating relation locks during sequence synchronizatio |
| Previous Message | Tom Lane | 2026-07-28 20:09:14 | pgsql: Fix planner's nullability/strictness logic for ScalarArrayOpExpr |