Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2 - Mailing list pgsql-general

From Jeff Janes
Subject Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Date
Msg-id CAMkU=1yUTpvnBHQ5fBJwbRkqddUY2iFxf0d+ZM4zXFL6wpTEOw@mail.gmail.com
Whole thread Raw
In response to Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-general
On Sat, Sep 10, 2016 at 7:09 PM, Jim Nasby <Jim.Nasby@bluetreble.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

pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Predicting query runtime
Next
From: Adrian Klaver
Date:
Subject: Re: Replication Recommendation