Documentation patch for backup manifests in protocol.sgml
Hi,
protocol.sgml describes the protocol messages received by a BASE_BACKUP
streaming command, but doesn't tell anything about the additional
CopyResponse data message containing the contents of the backup
manifest (if requested) after having received the tar files. So i
propose the attached to give a little more detail in this paragraph.
Thanks, Bernd
Attachments:
manifest_protocol_doc.patchtext/x-patch; charset=UTF-8; name=manifest_protocol_doc.patchDownload+4-2
On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote:
Hi,
protocol.sgml describes the protocol messages received by a BASE_BACKUP
streaming command, but doesn't tell anything about the additional
CopyResponse data message containing the contents of the backup
manifest (if requested) after having received the tar files. So i
propose the attached to give a little more detail in this paragraph.Thanks, Bernd
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 8b00235a516..31918144b37 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -2665,8 +2665,10 @@ The commands accepted in replication mode are: <quote>ustar interchange format</quote> specified in the POSIX 1003.1-2008 standard) dump of the tablespace contents, except that the two trailing blocks of zeroes specified in the standard are omitted. - After the tar data is complete, a final ordinary result set will be sent, - containing the WAL end position of the backup, in the same format as + After the tar data is complete, and if a backup manifest was requested, + another CopyResponse result is sent, containing the manifest data for the + current base backup. In any case, a final ordinary result set will be + sent, containing the WAL end position of the backup, in the same format as the start position. </para>
If someone can confirm this, I will apply it? Magnus?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Fri, Aug 21, 2020 at 06:03:32PM -0400, Bruce Momjian wrote:
On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote:
protocol.sgml describes the protocol messages received by a BASE_BACKUP
streaming command, but doesn't tell anything about the additional
CopyResponse data message containing the contents of the backup
manifest (if requested) after having received the tar files. So i
propose the attached to give a little more detail in this paragraph.If someone can confirm this, I will apply it? Magnus?
The reason why backup manifests are sent at the end of a base backup
is that they include the start and stop positions of the backup (see
caller of AddWALInfoToBackupManifest() in perform_base_backup()).
Once this is done, an extra CopyOutResponse message is indeed sent
within SendBackupManifest() in backup_manifest.c.
So confirmed.
--
Michael
On Mon, Aug 24, 2020 at 04:58:34PM +0900, Michael Paquier wrote:
On Fri, Aug 21, 2020 at 06:03:32PM -0400, Bruce Momjian wrote:
On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote:
protocol.sgml describes the protocol messages received by a BASE_BACKUP
streaming command, but doesn't tell anything about the additional
CopyResponse data message containing the contents of the backup
manifest (if requested) after having received the tar files. So i
propose the attached to give a little more detail in this paragraph.If someone can confirm this, I will apply it? Magnus?
The reason why backup manifests are sent at the end of a base backup
is that they include the start and stop positions of the backup (see
caller of AddWALInfoToBackupManifest() in perform_base_backup()).
Once this is done, an extra CopyOutResponse message is indeed sent
within SendBackupManifest() in backup_manifest.c.So confirmed.
Patch applied through 13.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Aug 31, 2020 at 06:48:53PM -0400, Bruce Momjian wrote:
Patch applied through 13.
Thanks.
--
Michael