Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: David Gibbons <david(at)dgibbons(dot)net>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Date: 2016-09-12 20:24:46
Message-ID: CAMkU=1yUTpvnBHQ5fBJwbRkqddUY2iFxf0d+ZM4zXFL6wpTEOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Sep 10, 2016 at 7:09 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 9/8/16 3:29 PM, David Gibbons wrote:
>
>>
>> Isn't this heading in the wrong direction? We need to be more
>> precise than 0 (since 0 is computed off of rounded/truncated time
>> stamps), not less precise than 0.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> Hmm, You may be right, reading it 4 more times for comprehension it
>> looks like it should be set to -1 not 1.
>>
>
> Not according to my man page:
>
> --modify-window
> When comparing two timestamps, rsync treats the timestamps
> as being equal if they differ by no more than the modify-window value.
> This is normally 0 (for an exact match), but you
> may find it useful to set this to a larger value in some
> situations. In particular, when transferring to or from an MS Windows FAT
> filesystem (which represents times with a
> 2-second resolution), --modify-window=1 is useful (allowing
> times to differ by up to 1 second).

Sorry, I can't tell what you are disputing here.

The man page you quote seems clear to me that setting it to 1, rather than
leaving it at 0, makes the opportunity for corruption wider, not narrower.

I thought that David's "-1" suggestions was tongue in cheek. But it turns
out that that actually does work. Of course, it works by forcing every
file to be copied, which removes the point of using this over
pg_basebackup, but nonetheless it would preserve the integrity of the data.

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-09-12 21:12:14 Re: Replication Recommendation
Previous Message Jeff Janes 2016-09-12 20:01:44 Re: Predicting query runtime