From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sameer Thakur <samthakur74(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Detach/attach table and index data files from one cluster to another |
Date: | 2013-04-12 16:12:13 |
Message-ID: | 20130412161213.GH30671@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan escribió:
>
> On 04/12/2013 10:15 AM, Tom Lane wrote:
> >Sameer Thakur <samthakur74(at)gmail(dot)com> writes:
> >>The proposed tool tries to make migration faster for tables and indices
> >>only by copying their binary data files.
> >There's 0 chance of making that work, because the two databases wouldn't
> >have the same notions of committed XIDs.
>
> Yeah. Trying to think way outside the box, could we invent some sort
> of fixup mechanism that could be applied to adopted files? Of
> course, that could slow things down so much that it wouldn't be
> worth it, but it might be a nice research project.
I think the fixup procedure involves freezing Xids (prior to the
transporting), which the OP said he didn't want to do.
If you don't freeze beforehand, there's not enough info in the new
cluster to know which tuples are dead/alive. Another option would be to
have a "private" copy of pg_clog/pg_subtrans for the transported
table(s), but that seems very difficult to arrange.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-04-12 16:14:24 | Re: Detach/attach table and index data files from one cluster to another |
Previous Message | Tom Lane | 2013-04-12 16:08:01 | Re: Analyzing bug 8049 |