Re: pg_rewind copies
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Daniel Gustafsson <daniel@yesql.se>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: David Steele <david@pgmasters.net>, Cary Huang <cary.huang@highgo.ca>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-04T13:08:12Z
Lists: pgsql-hackers
On 01.04.22 11:00, Daniel Gustafsson wrote: > One small comment on the patch: > > + snprintf(srcpath, sizeof(srcpath), "%s/%s", datadir, path); > > This should IMO check the returnvalue of snprintf to ensure it wasn't > truncated. While the risk is exceedingly small, a truncated filename might > match another existing filename and the error not getting caught. There is > another instance just like this one in open_target_file() to which I think we > should apply the same belts-and-suspenders treatment. I've fixed this in the > attached version which also have had a pg_indent run on top of a fresh rebase. We use snprintf() like that countless times, and approximately none of them check for overflow. So while you are right, this might not be the place to start a new policy. If you don't like this approach, use psprintf() perhaps.
Commits
-
pg_rewind: Fetch small files according to new size.
- 16915126746e 15.0 landed