From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Timeline ID in backup_label file |
Date: | 2017-11-16 03:09:05 |
Message-ID: | CAB7nPqQZvF0X_6q-fbpp4cxUj7967xrw=ESqmiwPAWPbtJfS-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 16, 2017 at 9:20 AM, David Steele <david(at)pgmasters(dot)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
Attachment | Content-Type | Size |
---|---|---|
backup_label_tli_v2.patch | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-11-16 03:38:17 | Treating work_mem as a shared resource (Was: Parallel Hash take II) |
Previous Message | Kyotaro HORIGUCHI | 2017-11-16 02:54:23 | Re: [HACKERS] path toward faster partition pruning |