Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: bharath.rupireddyforpostgres@gmail.com, orlovmg@gmail.com, alvherre@alvh.no-ip.org, nathandbossart@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2022-12-19T07:28:35Z
Lists: pgsql-hackers
On Tue, Dec 06, 2022 at 04:27:50PM +0900, Kyotaro Horiguchi wrote: > At Mon, 5 Dec 2022 10:03:55 +0900, Michael Paquier <michael@paquier.xyz> wrote in >> Hence I would tend to let XLogFromFileName do the job, while having a >> SQL function that is just a thin wrapper around it that returns the >> segment TLI and its number, leaving the offset out of the equation as >> well as this new XLogIdFromFileName(). > > I don't think it could be problematic that the SQL-callable function > returns a bogus result for a wrong WAL filename in the correct > format. Specifically, I think that the function may return (0/0,0) for > "000000000000000000000000" since that behavior is completely > harmless. If we don't check logid, XLogFromFileName fits instead. Yeah, I really don't think that it is a big deal either: XLogIdFromFileName() just translates what it receives from the caller for the TLI and the segment number. > (If we assume that the file names are typed in letter-by-letter, I > rather prefer to allow lower-case letters:p) Yep, makes sense to enforce a compatible WAL segment name if we can. -- Michael
Commits
-
Rename pg_dissect_walfile_name() to pg_split_walfile_name()
- 13e0d7a60385 16.0 landed
-
Add pg_dissect_walfile_name()
- cca186348929 16.0 landed
-
Add LSN location in some error messages related to WAL pages
- 71cb84ec69a3 16.0 landed