From: | Rosser Schwarz <rosser(dot)schwarz(at)gmail(dot)com> |
---|---|
To: | "Zheng, Wendy" <wendy(dot)zheng(at)emc(dot)com> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: The quickest way to migrate database within the same cluster |
Date: | 2015-01-04 07:19:29 |
Message-ID: | CAFnxYwhP1Nv_+n3p1WSqGnW0xCdDSPZ6o9zH+jEURCA2+b_e8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Sat, Jan 3, 2015 at 10:52 PM, Zheng, Wendy <wendy(dot)zheng(at)emc(dot)com> wrote:
> I’m working on a task to move tables from on database to another within
> the same cluster and same server...
>
Your second idea, of copying the underlying disk files, probably won't work
unless you're also copying all the relevant records from all of the system
catalog tables (a non-trivial task, itself), and likely not even then. (For
instance, if two tables in the different databases have the same
'relfilenode', you're going to overwrite that table in the second when you
perform the copy, and because those tables probably have different
structures, you'll then see "unexpected" behavior.)
You might instead try piping the output of a "COPY ($query) TO STDOUT" in a
psql session against the source database into a "COPY table FROM STDIN"
command in a psql session against the destination. That would filter on the
source side, but would require you to have empty tables of the expected
structure on the destination to receive the data.
rls
--
:wq
From | Date | Subject | |
---|---|---|---|
Next Message | Zheng, Wendy | 2015-01-04 07:30:06 | Re: The quickest way to migrate database within the same cluster |
Previous Message | Zheng, Wendy | 2015-01-04 07:14:28 | Re: The quickest way to migrate database within the same cluster |