Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Date: 2022-11-11 12:21:58
Message-ID: CACG=ezbzyj+y26-3jFfw_ZgGRguDf-9ywSRK2LCkejKktQTqBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-11-11 12:34:41 Re: Printing backtrace of postgres processes
Previous Message David Geier 2022-11-11 12:01:15 Optimize join selectivity estimation by not reading MCV stats for unique join attributes