Re: pg_rewind copies
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: 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-01T09:00:00Z
Lists: pgsql-hackers
Attachments
- v3-0001-pg_rewind-Fetch-small-files-according-to-new-size.patch (application/octet-stream) patch v3-0001
I took another look at this patch, and I think it's ready to go in, it clearly fixes a bug that isn't too hard to hit in production settings. To ensure we don't break this I've added a testcase which pipes the pg_rewind --verbose output to a file it's asked to copy, which then guarantees that the file is growing in size during the operation without need for synchronizing two processes with IPC::Run (it also passes on Windows in the CI setup). 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. Thoughts on this version? -- Daniel Gustafsson https://vmware.com/
Commits
-
pg_rewind: Fetch small files according to new size.
- 16915126746e 15.0 landed