From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] reorder tablespaces in basebackup tar stream for backup_label |
Date: | 2017-02-22 12:23:52 |
Message-ID: | 1487766232.3143.10.camel@oopsware.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-02-22 12:24:27 | Re: dropping partitioned tables without CASCADE |
Previous Message | Petr Jelinek | 2017-02-22 12:07:46 | Re: snapbuild woes |