On Tue, Apr 5, 2016 at 5:35 PM, Magnus Hagander <mag...@hagander.net> wrote:
> > > On Mon, Apr 4, 2016 at 3:15 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > >> On Mon, Apr 4, 2016 at 4:31 PM, Magnus Hagander <mag...@hagander.net> >> wrote: >> >>> On Fri, Apr 1, 2016 at 6:47 AM, Amit Kapila <amit.kapil...@gmail.com> >>> wrote: >>> >>> >>>> Also, I think below part of documentation for pg_start_backup() needs >>>> to be modified: >>>> >>>> <para> >>>> >>>> <function>pg_start_backup</> accepts an >>>> >>>> arbitrary user-defined label for the backup. (Typically this would >>>> be >>>> >>>> the name under which the backup dump file will be stored.) The >>>> function >>>> >>>> writes a backup label file (<filename>backup_label</>) and, if >>>> there >>>> >>>> are any links in the <filename>pg_tblspc/</> directory, a >>>> tablespace map >>>> >>>> file (<filename>tablespace_map</>) into the database cluster's data >>>> >>>> directory, performs a checkpoint, and then returns the backup's >>>> starting >>>> >>>> transaction log location as text. The user can ignore this result >>>> value, >>>> >>>> but it is provided in case it is useful. >>>> >>> >>> That one definitely needs to be fixed, as it's part of the reference. >>> Good spot. >>> >>> >>> >>>> Similarly, there is a description for pg_stop_backup which needs to be >>>> modified. >>>> >>> >>> That's the one you're referring to in your first commend above, is it >>> not? Or is there one more that you mean? >>> >>> >> I am referring to below part of docs in func.sgml >> >> <para> >> >> <function>pg_stop_backup</> removes the label file and, if it exists, >> >> the <filename>tablespace_map</> file created by >> >> <function>pg_start_backup</>, and creates a backup history file in >> >> the transaction log archive area. The history file includes the >> label given to >> >> <function>pg_start_backup</>, the starting and ending transaction >> log locations for >> >> the backup, and the starting and ending times of the backup. The >> return >> >> value is the backup's ending transaction log location (which again >> >> can be ignored). After recording the ending location, the current >> >> transaction log insertion >> >> point is automatically advanced to the next transaction log file, so >> that the >> >> ending transaction log file can be archived immediately to complete >> the backup. >> >> </para> >> >> > Ah, gotcha. Clearly I wasn't paying attention properly. > > PFA a better one (I think), also with the rename and added comments that > David was asking for. > > This version looks good. Apart from review, I have done some tests (including regression test), everything seems to be fine. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
