Hello, At Wed, 29 Mar 2017 09:23:42 +0200, Michael Banck <michael.ba...@credativ.de> wrote in <1490772222.18436.14.ca...@credativ.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.fu...@gmail.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers