Re: Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment

From: solai v <solai(dot)cdac(at)gmail(dot)com>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment
Date: 2026-05-17 14:50:50
Message-ID: CAF0whuf7UH8Zc=4z=d71yvOBqFd+Jsz9H+3Du__f6XgN2Eu3og@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Matthias,

I reviewed the v2 patch and tested it on my local build.

I verified that before the patch, mdunlinkfiletag() ignored forknum
and segno and always operated on MAIN_FORKNUM segment 0.
The new direction with register_unlink_tombstone() makes the intent
much clearer, and the added Assert() looks like a good safeguard
against accidental misuse.

I also had a small comment suggestion near the Assert() to make the
tombstone-only behavior slightly more explicit.
The patch applied successfully with git apply --3way, and PostgreSQL
built and tested successfully on my setup.

Overall the patch looks good to me.

Regards,
Solai

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2026-05-17 15:00:00 035_standby_logical_decoding might fail due to FATAL message lost inside libpq
Previous Message Sami Imseih 2026-05-17 14:34:01 pgstat: Flush some statistics within running transactions, take 2