Hi, On Fri, Aug 21, 2026 at 12:25 PM Bertrand Drouvot <[email protected]> wrote: > > 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. >
Thanks, that's a valid concern. Logging XLOG_SMGR_CREATE before smgrcreate() would break the established ordering, and could allow a concurrent checkpoint's redo pointer to advance past the create record before the physical file has actually been created and registered for synchronization. The separate PRECREATE approach in [1] looks like it could be reused independently of its undo infrastructure. PRECREATE could represent just the intent to create the durable marker, while the existing CREATE record would retain its normal position after physical file creation. I'll explore this possibility further and incorporate it into the next version of the patch. > Could this be reused here, independently of the rest of its undo > infrastructure? > > [1]: > https://postgr.es/m/CAEepm%3D0ULqYgM2aFeOnrx6YrtBg3xUdxALoyCG%2BXpssKqmezug%40mail.gmail.com > -- With Regards, Ashutosh Sharma.
