On Fri, Apr 12, 2013 at 9:52 PM, Andres Freund wrote:
> On 2013-04-12 12:14:24 -0400, Tom Lane wrote:
> > Andrew Dunstan writes:
> > > On 04/12/2013 10:15 AM, Tom Lane wrote:
> > >> There's 0 chance of making that work, because the two databases
> wouldn't
> > >> have the same notions of committe
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The big win here over a binary COPY is pulling through the indexes as-is
> > as well- without having to rebuild them.
[... lots of reasons this is hard ...]
I agree that it's quite a bit more difficult, to the point that logical
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I suppose it would still be faster than a COPY transfer, but I'm not
>> sure it'd be enough faster to justify the work and the additional
>> portability hits you'd be taking.
> The big win here over a binary COPY is pulling through
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, it wouldn't be that hard to replace XIDs with FrozenXID or
> InvalidXID as appropriate, if you had access to the source database's
> clog while you did the copying. It just wouldn't be very fast.
If you're doing that in a streaming method, it strikes
On Fri, Apr 12, 2013 at 10:22:38PM +0530, Pavan Deolasee wrote:
>
>
>
> On Fri, Apr 12, 2013 at 9:44 PM, Tom Lane wrote:
>
> Andrew Dunstan writes:
> > On 04/12/2013 10:15 AM, Tom Lane wrote:
> >> There's 0 chance of making that work, because the two databases
> wouldn't
> >>
On Fri, Apr 12, 2013 at 9:44 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 04/12/2013 10:15 AM, Tom Lane wrote:
> >> 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
On 2013-04-12 12:14:24 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 04/12/2013 10:15 AM, Tom Lane wrote:
> >> 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
Andrew Dunstan writes:
> On 04/12/2013 10:15 AM, Tom Lane wrote:
>> 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 appli
Andrew Dunstan escribió:
>
> On 04/12/2013 10:15 AM, Tom Lane wrote:
> >Sameer Thakur 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
> >hav
On 04/12/2013 10:15 AM, Tom Lane wrote:
Sameer Thakur 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.
Y
Sameer Thakur 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. You apparently don't
understand what you re
Hello,
The current process of transferring data files from one cluster to another
by using pg_dump and pg_restore is time consuming.
The proposed tool tries to make migration faster for tables and indices
only by copying their binary data files. This is like pg_upgrade but used
for migration of t
12 matches
Mail list logo
