Re: [PATCH] pg_basebackup: progress report max once per second

From: Oskari Saarenmaa <os(at)ohmu(dot)fi>
To: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Cc: Mika Eloranta <mel(at)ohmu(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pg_basebackup: progress report max once per second
Date: 2014-02-01 11:29:39
Message-ID: 52ECDAA3.4060800@ohmu.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

31.01.2014 10:59, Sawada Masahiko kirjoitti:
> On Tue, Jan 21, 2014 at 7:17 AM, Oskari Saarenmaa <os(at)ohmu(dot)fi> wrote:
>> 18.11.2013 07:53, Sawada Masahiko kirjoitti:
>>>>
>>>> On 13 Nov 2013, at 20:51, Mika Eloranta <mel(at)ohmu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-02-01 12:32:46 Re: [PATCH] Support for pg_stat_archiver view
Previous Message Christian Kruse 2014-02-01 10:41:54 Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire