| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(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-24 19:45:09 |
| Message-ID: | c00b4179-7da2-dec1-e5db-a184eea44e79@BlueTreble.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 9/12/16 3:24 PM, Jeff Janes wrote:
> 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.
Yeah, I actually read it backwards. :/ I don't see how --modify-window
is helpful at all here; you need to use --ignore-times.
> 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.
AFAIK pg_basebackup blindly copies all data files, while rsync will
transfer only the parts of the files that have actually changed (see
--block-size). If the source and destination are on different servers,
that can mean less data transferred over the network.
--
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 | Leonardo M. Ramé | 2016-09-24 20:42:41 | Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2 |
| Previous Message | Vitaly Burovoy | 2016-09-24 13:31:16 | Re: jsonb_set for nested new item? |