Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Maxim Orlov <orlovmg@gmail.com>
From: Maxim Orlov <orlovmg@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2022-11-11T12:21:58Z
Lists: pgsql-hackers
Hi! I've watched over the patch and consider it useful. Applies without conflicts. The functionality of the patch itself is meets declared functionality. But, in my view, some improvements may be proposed. We should be more, let's say, cautious (or a paranoid if you wish), in pg_walfile_offset_lsn while dealing with user input values. What I mean by that is: - to init input vars of sscanf, i.e. tli, log andseg; - check the return value of sscanf call; - check filename max length. Another question arises for me: is this function can be called during recovery? If not, we should ereport about this, should we? And one last note here: pg_walfile_offset_lsn is accepting NULL values and return NULL in this case. From a theoretical point of view, this is perfectly fine. Actually, I think this is exactly how it supposed to be, but I'm not sure if there are no other opinions here. -- Best regards, Maxim Orlov.
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