MIME-Version: 1.0
From: Shiju Sivadazz <shijusivadazz86@gmail.com>
Date: Wed, 11 Mar 2026 19:15:08 +0530
Message-ID: <CAERa5bB=t9VGqsrhQ43vxYC_mH5XkQWKW_KOUn04dTNN7a-R-g@mail.gmail.com>
Subject: Question about heap_inplace_update and VACUUM behavior
To: pgsql-general@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d3ee14064cbfd84f"
Archived-At: <https://www.postgresql.org/message-id/CAERa5bB%3Dt9VGqsrhQ43vxYC_mH5XkQWKW_KOUn04dTNN7a-R-g%40mail.gmail.com>
Precedence: bulk

--000000000000d3ee14064cbfd84f
Content-Type: text/plain; charset="UTF-8"

Hello PostgreSQL Hackers,

I am currently exploring the PostgreSQL source code to better understand
the internal storage and update mechanisms. While reviewing the heap access
methods, I noticed the function heap_inplace_update() in the source code
with the following comment:

/*
 * heap_inplace_update - deprecated
 *
 * This exists only to keep modules working in back branches. Affected
 * modules should migrate to systable_inplace_update_begin().
 */

From my understanding, PostgreSQL generally follows the MVCC model, where
updates create a new tuple version rather than modifying the existing tuple
in place.

This raised a few questions for me:

   1.

   Does PostgreSQL still support any form of in-place updates internally,
   or is this function strictly kept for backward compatibility?
   2.

   What types of system catalog operations (if any) rely on in-place
   updates through systable_inplace_update_begin()?
   3.

   Since in-place updates do not generate a new tuple version, how does
   VACUUM interact with such updates? Does it need to handle them differently
   compared to normal MVCC updates?
   4.

   Are there any performance or concurrency considerations that influenced
   the decision to deprecate heap_inplace_update in favor of the newer APIs?

I would greatly appreciate any clarification or references to relevant
documentation or design discussions.

Thank you for your time and for the incredible work on PostgreSQL.

Best regards,
Shiju
Software Developer
Currently studying PostgreSQL internals

--000000000000d3ee14064cbfd84f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello PostgreSQL Hackers,</p><p>I am currently explorin=
g the PostgreSQL source code to better understand the internal storage and =
update mechanisms. While reviewing the heap access methods, I noticed the f=
unction=C2=A0<code dir=3D"ltr">heap_inplace_update()</code>=C2=A0in the sou=
rce code with the following comment:</p><pre dir=3D"ltr" style=3D"text-wrap=
-mode: wrap;"><code dir=3D"ltr">/*
 * heap_inplace_update - deprecated
 *
 * This exists only to keep modules working in back branches. Affected
 * modules should migrate to systable_inplace_update_begin().
 */</code></pre><p>From my understanding, PostgreSQL generally follows the =
MVCC model, where updates create a new tuple version rather than modifying =
the existing tuple in place.</p><p>This raised a few questions for me:</p><=
ol start=3D"1"><li style=3D"margin-left:15px"><p>Does PostgreSQL still supp=
ort any form of in-place updates internally, or is this function strictly k=
ept for backward compatibility?</p></li><li style=3D"margin-left:15px"><p>W=
hat types of system catalog operations (if any) rely on in-place updates th=
rough=C2=A0<code dir=3D"ltr">systable_inplace_update_begin()</code>?</p></l=
i><li style=3D"margin-left:15px"><p>Since in-place updates do not generate =
a new tuple version, how does VACUUM interact with such updates? Does it ne=
ed to handle them differently compared to normal MVCC updates?</p></li><li =
style=3D"margin-left:15px"><p>Are there any performance or concurrency cons=
iderations that influenced the decision to deprecate=C2=A0<code dir=3D"ltr"=
>heap_inplace_update</code>=C2=A0in favor of the newer APIs?</p></li></ol><=
p>I would greatly appreciate any clarification or references to relevant do=
cumentation or design discussions.</p><p>Thank you for your time and for th=
e incredible work on PostgreSQL.</p><p>Best regards,<br>Shiju<br>Software D=
eveloper<br>Currently studying PostgreSQL internals</p></div>

--000000000000d3ee14064cbfd84f--