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.
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 |