Re: pg_rewind copies - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: pg_rewind copies
Date
Msg-id FBE3D7A0-4291-40F1-B4B7-637A440686C7@yesql.se
Whole thread Raw
In response to Re: pg_rewind copies  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pg_rewind copies  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: pg_rewind copies  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
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/


Attachment

pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Unit tests for SLRU
Next
From: David Rowley
Date:
Subject: Re: Use generation context to speed up tuplesorts