On Fri, Nov 4, 2016 at 3:44 PM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Fri, Nov 4, 2016 at 1:18 PM, Venkata B Nagothi <nag1...@gmail.com> > wrote: > > I see the following contents in the file > > "000000010000000000000044.00000060.backup" which was generated in the > pg_wal > > location during the online backup. When pg_stop_backup() is executed, the > > following content is written which includes the content copied from the > > backup_label file. > > > > [...] > > > > Can someone please help me know the importance of the above file? > > It is not actually critical, and useful for debugging (you could say > the same about backup_label.old). > > > How about having the same contents in the backup_label file as well? > > > As of now, the backup_label file does not have any information related to > > when and at what position the backup actually completed. > > Yes, and it is not actually possible to write the stop information > because when a backup finishes the backup_label is simply removed and > it has been included in the backup before it finishes. The role of > this file is to provide the LSN start location from which the backup > is able to replay things cleanly. The stop position, aka when > everything on disk is consistent, is determined at replay by the > XLOG_BACKUP_END record. This stop position is not something you can > know when the backup_label file is generated. And I am of course > talking about exclusive backups here. > Sure. I will look at the possibility of using XLOG_BACKUP_END in my patch. I am looking at the possibility of keeping the backup_label at source until pg_stop_backup() is executed and then write the STOP information and then move it across to the backup location. I see that when the START/STOP information is written to the WAL history file, the content from the backup_label file is being copied and I am thinking to do the same other way around. Am i making sense ? is that anyway not possible ? If this makes sense, then i would start working on an optimal design and look at the possibility of achieving this. Regards, Venkata B N Database Consultant Fujitsu Australia
