Re: Detach/attach table and index data files from one cluster to another

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

In response to

Browse pgsql-hackers by date

  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