On Fri, Mar 31, 2017 at 02:11:44PM +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 31 Mar 2017 13:37:38 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQU1H=PAG3XBYFFg9w+emeQFYAdkep7cWVeJukXtB_m_Q@mail.gmail.com>
> > In my first reviews of the patch, I completely forgot the fact that
> > BASE_BACKUP does send the start LSN of the backup in the first result
> > set, so the patch proposed is actually rather useless because the data
> > you are looking for is already at hand. If more data would be
> > interesting to have, like the start timestamp number, we could just
> > extend the first result set a bit as Fujii-san is coming at. Let's
> > drop this patch and move on.
>
> +1 for dropping this.
I've marked it as "Rejected" now, as that is clearly the consensus.
> But I think we should edit the documentation a bit.
>
> I don't fully understand those who want to handle it by a script,
> but the documentation seems to be suggesting that something like
> is possible. So it might be better add a description like that or
> just remove the example.
The documentation says "For the purpose of testing replication
commands", one could use psql and "IDENTIFY_SYSTEM", it doesn't exactly
suggest to run BASE_BACKUP this way.
Which, by the way, appears to be working totally fine from psql, modulo
the problem that you won't get to the starting transaction location.
> "psql doesn't handle this protocol properly. The instances of the
> usage of these protocols are found in the source code of
> walreceiver and pg_basebackup."
Something along those lines makes sense I think, yeah.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
