>>> I don't much like that approach. The standby would need to be able to >>> write the backup history file to the archive at the end of backup, and >>> we'd have to reintroduce the code to fetch it from archive and, when >>> streaming, from the master. At the moment, the archiver doesn't even run >>> in the standby. >> >> Please teach the reason for "The standby would need to be able to write >> the backup history file to the archive at the end of backup" . >> (I'd like to know why "to only pg_xlog" is wrong .) > > If the backup history file is not archived, the postgres process won't > find it when you try to restore from the base backup. The new server has > no access to the standby's pg_xlog directory.
Thanks for the answer . But , it sends the backup history file to pg_xlog of new server (=backup server) when pg_basebackup is executed to the standby server , and so I was going to create the patch of such logic . I think it don't become the above-mentioned movement . >> Because there is the opinion of "Cascade replication" , I don't want to >> realize the function with the method which the standby requests to execute >> it on the primary server . >> >> (The opinion of "Cascade replication"： >> http://archives.postgresql.org/pgsql-hackers/2011-05/msg01150.php) > >I don't see how this helps. Hypothesis: * Online base backup was realized with the method which the standby requests to execute it on the "primary server" . * "Cascade replication" was developed , and user is using it . (Ex. Primary -- Standby1 -- Standby2) Situation: (1) Standby2 executes pg_basebackup . (2) Then, Standby2 accesses Standby1 . (3) But, it fails, because Standby2's primary is Standby1, not Primary . Result: * I don't want to realize the function with the method which the standby requests to execute it on the primary server . -------------------------------------------- Jun Ishizuka NTT Software Corporation TEL：045-317-7018 E-Mail: ishizuka....@po.ntts.co.jp -------------------------------------------- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
