From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Clarification on using pg_upgrade |
Date: | 2016-03-11 16:46:42 |
Message-ID: | 56E2F672.7080305@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 3/4/16 4:58 PM, Justin Pryzby wrote:
> On Fri, Mar 04, 2016 at 02:27:59PM -0800, Tory M Blue wrote:
>> >If my data is located in /data
>> >
>> >and I link to a new dir in /data1, what actually happens. do I end up with
>> >2 file systems and links and thus am not able to delete or cleanup any old
>> >data, or how does this work?
>> >
>> >Also will the reindex creation still happen with this type of in-place
>> >upgrade, as if so, then it may not save too much time vs a dump/import.
> Since you have the space, you can do a test upgrade; make a dump of the
> essential tables (or the entire thing) and restore it to another instance,
> perhaps even something run from your /home.
Since pg_upgrade operates at a binary level, if you want to test it I'd
recommend using a PITR backup and not pg_dump. It's theoretically
possible to have a database that will pg_dump correctly but that
pg_upgrade chokes on.
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Artem Tomyuk | 2016-03-13 17:39:38 | DIsk I/O from pg_stat_activity |
Previous Message | Jim Nasby | 2016-03-11 16:37:35 | Re: [SPAM] Re: Architectural question |