Re: [PATCH] pg_basebackup: progress report max once per second - Mailing list pgsql-hackers

From Oskari Saarenmaa
Subject Re: [PATCH] pg_basebackup: progress report max once per second
Date
Msg-id 52ECDAA3.4060800@ohmu.fi
Whole thread Raw
In response to Re: [PATCH] pg_basebackup: progress report max once per second  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: [PATCH] pg_basebackup: progress report max once per second  (Sawada Masahiko <sawada.mshk@gmail.com>)
List pgsql-hackers
31.01.2014 10:59, Sawada Masahiko kirjoitti:
> On Tue, Jan 21, 2014 at 7:17 AM, Oskari Saarenmaa <os@ohmu.fi> wrote:
>> 18.11.2013 07:53, Sawada Masahiko kirjoitti:
>>>>
>>>> On 13 Nov 2013, at 20:51, Mika Eloranta <mel@ohmu.fi> wrote:
>>>>>
>>>>> Prevent excessive progress reporting that can grow to gigabytes
>>>>> of output with large databases.
>>>
>>>
>>> I got error with following scenario.
>>>
>>> $ initdb -D data -E UTF8 --no-locale
>>> /* setting the replication parameters */
>>> $ pg_basebackup -D 2data
>>> Floating point exception
>>> LOG:  could not send data to client: Broken pipe
>>> ERROR:  base backup could not send data, aborting backup
>>> FATAL:  connection to client lost
>>
>>
>> Attached a rebased patch with a fix for division by zero error plus some
>> code style issues.  I also moved the patch to the current commitfest.
>>
>
> Thank you for updating the patch!
> I have reviewed it easily.
>
> I didn't get error of compile, and the patch works fine.
>
> I have one question.
> What does it mean the calling progress_report() which you added at end
> of ReceiveUnpackTarFile() and RecieveTarFile()?
> I could not understand necessity of this code. And the force argument
> of progress_report() is also same.
> If you would like to use 'force' option, I think that you should add
> the comment to source code about it.

I think the idea in the new progress_report() call (with force == true) 
is to make sure that there is at least one progress_report call that 
actually writes the progress report.  Otherwise the final report may go 
missing if it gets suppressed by the time-based check.  The force 
argument as used in the new call skips that check.

/ Oskari



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Support for pg_stat_archiver view