Re: [HACKERS] Timeline ID in backup_label file

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
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

In response to

Responses

Browse pgsql-hackers by date

  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