Re: [HACKERS] [patch] reorder tablespaces in basebackup tar streamfor backup_label - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: [HACKERS] [patch] reorder tablespaces in basebackup tar streamfor backup_label
Date
Msg-id 1487766232.3143.10.camel@oopsware.de
Whole thread Raw
In response to [HACKERS] [patch] reorder tablespaces in basebackup tar stream forbackup_label  (Michael Banck <michael.banck@credativ.de>)
Responses Re: [HACKERS] [patch] reorder tablespaces in basebackup tar streamfor backup_label  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Am Dienstag, den 21.02.2017, 11:17 +0100 schrieb Michael Banck:
> However, third party tools using the BASE_BACKUP command might want
> to
> extract the backup_label, e.g. in order to figure out the START WAL
> LOCATION. If they make a big tarball for the whole cluster
> potentially
> including all external tablespaces, then the backup_label file is
> somewhere in the middle of it and it takes a long time for tar to
> extract it.
> 
> So I am proposing the attached patch, which sends the base tablespace
> first, and then all the other external tablespaces afterwards, thus
> having base_backup be the first file in the tar in all cases. Does
> anybody see a problem with that?
> 
> 
> Michael
> 
> [1] Chapter 52.3 of the documentation says "one or more CopyResponse
> results will be sent, one for the main data directory and one for
> each
> additional tablespace other than pg_default and pg_global.", which
> makes
> it sound like the main data directory is first, but in my testing,
> this
> is not the case.

The comment in the code says explicitely to add the base directory to
the end of the list, not sure if that is out of a certain reason.

I'd say this is an oversight in the implementation. I'm currently
working on a tool using the streaming protocol directly and i've
understood it exactly the way, that the default tablespace is the first
one in the stream.

So +1 for the patch.



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] snapbuild woes
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] dropping partitioned tables without CASCADE