Re: avoid multiple hard links to same WAL file after a crash - Mailing list pgsql-hackers

From Robert Haas
Subject Re: avoid multiple hard links to same WAL file after a crash
Date
Msg-id CA+TgmobGi7b-5fjAWgEO0ebn516n0OyOi-j7+Hyz_j9sAG17og@mail.gmail.com
Whole thread Raw
In response to Re: avoid multiple hard links to same WAL file after a crash  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: avoid multiple hard links to same WAL file after a crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 11, 2022 at 5:12 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> So, the only thing we need to care is segment switch. Without it, the
> segment that InstallXLogFileSegment found by the stat loop is known to
> be safe to overwrite even if exists.
>
> When segment switch finds an existing file, it's no problem since the
> segment switch doesn't create a new segment.  Otherwise segment switch
> always calls InstallXLogFileSegment.  The section from searching for
> an empty segmetn slot until calling durable_rename_excl() is protected
> by ControlFileLock. Thus if a process is in the section, no other
> process can switch to a newly-created segment.
>
> If this diagnosis is correct, the comment is proved to be paranoid.

It's sometimes difficult to understand what problems really old code
comments are worrying about. For example, could they have been
worrying about bugs in the code? Could they have been worrying about
manual interference with the pg_wal directory? It's hard to know.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: SQL/JSON: functions
Next
From: Tom Lane
Date:
Subject: Re: SQL/JSON: functions