On Thu, Nov 16, 2017 at 9:20 AM, David Steele <da...@pgmasters.net> wrote: > For this patch at least, I think we should do #1. Getting rid of the order > dependency is attractive but there may be other programs that are depending > on the order. I know you are not proposing to change the order now, but it > *could* be changed with #2.
read_backup_label() is a static function in the backend code. With #2
I do not imply to change the order of the elements written in the
backup_label file, just to make the way they are parsed smarter.
> Also, I think DEBUG1 would be a more appropriate log level if any logging is
> done.
OK, the label and time strings can include spaces. The label string is
assumed to not be bigger than 1028 bytes, and the timestamp is assumed
that it can get up to 128. So it is possible to use stuff like
fscanf("%127[^\n]\n") to avoid any buffer overflow problems on the
backend. If a backup_label is generated with strings longer than that,
then read_backup_label would fail to parse the next entries but that's
not really something to worry about IMO as those are only minor sanity
checks. Having a safer coding in the backend is more important, and
the new checks should not trigger any hard failures.
--
Michael
backup_label_tli_v2.patch
Description: Binary data
