Date: Fri, 21 Aug 2026 06:55:19 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
	Andres Freund <andres@anarazel.de>
Subject: Re: Orphaned Files in PostgreSQL
Message-ID: <aof2V2jdcD67HPeO@bdtpg>
References: 
 <CAE9k0Pno=Mns7J5HA4+bbXzb=yCZnCtSF_wf1ZipCQxardKDjA@mail.gmail.com>
 <CAE9k0Pnd3fAGGJjxRPv3CqH1AiRB-1Y=4_Ah-XV9hC7ZZQXK_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAE9k0Pnd3fAGGJjxRPv3CqH1AiRB-1Y=4_Ah-XV9hC7ZZQXK_w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aof2V2jdcD67HPeO%40bdtpg>
Precedence: bulk

Hi,

On Thu, Aug 20, 2026 at 02:40:25PM +0530, Ashutosh Sharma wrote:
> Hi All,
> 
> I am revisiting this thread to propose a possible fix for this known issue.

Thanks for working on this!

> This ordering guarantees that relation storage cannot become durable
> without either a durable marker or WAL capable of reconstructing that
> marker.

I wonder if logging XLOG_SMGR_CREATE before smgrcreate() could interact badly
with a concurrent checkpoint? I looked at [1] and it looks like it used a separate
PRECREATE record and kept the usual CREATE record after physical creation.

Could this be reused here, independently of the rest of its undo infrastructure?

[1]: https://postgr.es/m/CAEepm%3D0ULqYgM2aFeOnrx6YrtBg3xUdxALoyCG%2BXpssKqmezug%40mail.gmail.com

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com