Thread

1. avoid unnecessary failure to open restored WAL files

   Fujii Masao <masao.fujii@gmail.com> — 2012-08-02T16:18:43Z

   Hi,
   
   In HEAD and 9.2, the following scenario happens in archive recovery.
   
   1. The archived WAL file is restored onto the temporary file name
   "RECOVERYXLOG".
   2. The restored WAL file is renamed to the correct file name like
   000000010000000000000002.
   3. The startup process tries to open the temporary file even though
   it's already been renamed
       and doesn't exist. This always fails.
   4. The startup process retries to open the correct file as a WAL file
   in pg_xlog directory instead
       of the archived file. This succeeds.
   
   The above failure of file open is unnecessary, so I think we can avoid
   that. Attached patch
   changes the startup process so that it opens the correct restored WAL
   file after restoring the
   archived WAL file.
   
   Regards,
   
   -- 
   Fujii Masao
   

2. Re: avoid unnecessary failure to open restored WAL files

   Simon Riggs <simon@2ndquadrant.com> — 2012-08-07T18:08:54Z

   On 2 August 2012 17:18, Fujii Masao <masao.fujii@gmail.com> wrote:
   > Hi,
   >
   > In HEAD and 9.2, the following scenario happens in archive recovery.
   >
   > 1. The archived WAL file is restored onto the temporary file name
   > "RECOVERYXLOG".
   > 2. The restored WAL file is renamed to the correct file name like
   > 000000010000000000000002.
   > 3. The startup process tries to open the temporary file even though
   > it's already been renamed
   >     and doesn't exist. This always fails.
   > 4. The startup process retries to open the correct file as a WAL file
   > in pg_xlog directory instead
   >     of the archived file. This succeeds.
   >
   > The above failure of file open is unnecessary, so I think we can avoid
   > that. Attached patch
   > changes the startup process so that it opens the correct restored WAL
   > file after restoring the
   > archived WAL file.
   
   Looks to me that the strncpy is backwards and will still fail.  Please
   double check.
   
   -- 
    Simon Riggs                   http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services
   
   

3. Re: avoid unnecessary failure to open restored WAL files

   Fujii Masao <masao.fujii@gmail.com> — 2012-08-08T17:31:22Z

   On Wed, Aug 8, 2012 at 3:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
   > On 2 August 2012 17:18, Fujii Masao <masao.fujii@gmail.com> wrote:
   >> Hi,
   >>
   >> In HEAD and 9.2, the following scenario happens in archive recovery.
   >>
   >> 1. The archived WAL file is restored onto the temporary file name
   >> "RECOVERYXLOG".
   >> 2. The restored WAL file is renamed to the correct file name like
   >> 000000010000000000000002.
   >> 3. The startup process tries to open the temporary file even though
   >> it's already been renamed
   >>     and doesn't exist. This always fails.
   >> 4. The startup process retries to open the correct file as a WAL file
   >> in pg_xlog directory instead
   >>     of the archived file. This succeeds.
   >>
   >> The above failure of file open is unnecessary, so I think we can avoid
   >> that. Attached patch
   >> changes the startup process so that it opens the correct restored WAL
   >> file after restoring the
   >> archived WAL file.
   >
   > Looks to me that the strncpy is backwards and will still fail.  Please
   > double check.
   
   Oh, you're right. I wrongly placed two arguments "source" and "destination"
   of strncpy in the reverse order... Attached is the updated version of the patch.
   
   Regards,
   
   -- 
   Fujii Masao