From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | michael(dot)banck(at)credativ(dot)de |
Cc: | michael(dot)paquier(at)gmail(dot)com, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [patch] reorder tablespaces in basebackup tar stream for backup_label |
Date: | 2017-03-29 08:36:30 |
Message-ID: | 20170329.173630.18447427.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Wed, 29 Mar 2017 09:23:42 +0200, Michael Banck <michael(dot)banck(at)credativ(dot)de> wrote in <1490772222(dot)18436(dot)14(dot)camel(at)credativ(dot)de>
> Hi,
>
> Am Mittwoch, den 29.03.2017, 15:22 +0900 schrieb Michael Paquier:
> > On Wed, Mar 29, 2017 at 3:56 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > > If your need other information except START WAL LOCATION at the beginning of
> > > base backup and they are very useful for many third-party softwares,
> > > you can add them into that first result set. If you do this, you can
> > > retrieve them
> > > at the beginning even when WAL files are included in the backup.
> >
> > You mean in the result tuple of pg_start_backup(), right? Why not.
>
> The replication protocol chapter says: "When the backup is started, the
> server will first send two ordinary result sets, followed by one or more
> CopyResponse results. The first ordinary result set contains the
> starting position of the backup, in a single row with two columns."
>
> However, I don't think it is very obvious to users (or at least it is
> not to me) how to get at this from psql, if you want to script it. If I
> run something like 'psql "dbname=postgres replication=database" -c
> "BASE_BACKUP" "> foo', I seem to only get the tar file(s), unless I am
> missing something.
Interesting. The protocol documentation seems fine to me but
maybe the example is perplexing. psql always prints only the last
result set for a query. So your query resembling the example in
the page gives only unrecognizable dump.
A little modification to psql prints the follwing but anyway
modifying psql to handle BASE_BACKUP like this doesn't seem
reasonable.
$ psql "dbname=postgres replication=database port=5433" -c "BASE_BACKUP" | head
recptr | tli
-----------+-----
0/C000028 | 1
(1 row)
spcoid | spclocation | size
--------+-------------+------
| |
(1 row)
backup_labelgres0000000E)
CHECKPOINT LOCATION: 0/E000060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2017-03-29 17:32:16 JST
LABEL: base backup
....
> The reason one might not want to run pg_basebackup directly is that this
> way one can pipe the output to an external program, e.g. to better
> compress it; this is not possible with pg_basebackup if you additional
> tablespaces.
>
> So I think that has some merit on its own.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | vinayak | 2017-03-29 08:38:14 | Re: ANALYZE command progress checker |
Previous Message | Kang Yuzhe | 2017-03-29 08:29:17 | Re: On How To Shorten the Steep Learning Curve Towards PG Hacking... |