From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | 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-07 23:49:49 |
Message-ID: | db683c18-975a-fb4a-bf30-5a8df3d5feb3@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Please include the mailing list in replies...
On 9/7/16 6:10 PM, David Gibbons wrote:
> That is NOT safe. The problem is it allows rsync to use mtime alone
> to decide that a file is in sync, and that will fail if Postgres
> writes to a file in the same second that the first rsync reads from
> it (assuming Postgres writes after rsync reads). You need to add the
> --checksum flag to rsync (which means it will still have to read
> everything that's in /var/lib/pgsql).
>
>
> The checksum flag as you mention is not performant,
Definitely not. :/
> If this is a concern, you're much better using the *--modify-window *flag:
> 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.
>
> Hence, rsync -va --modify-window=1 would remove your concern about a
> same second race condition without forcing the sync to read through all
> the files.
Very interesting and useful!
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick B | 2016-09-08 00:31:28 | Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2 |
Previous Message | Jim Nasby | 2016-09-07 23:46:34 | Re: What limits Postgres performance when the whole database lives in cache? |