Re: Changeset Extraction v7.6.1

On 01-06-2014 02:57, Andres Freund wrote:
> On 2014-06-01 00:50:58 -0500, Jim Nasby wrote:
>> On 5/31/14, 9:11 AM, Andres Freund wrote:
>>> On 2014-02-21 15:14:15 -0600, Jim Nasby wrote:
>>>> On 2/17/14, 7:31 PM, Robert Haas wrote:
>>>>> But do you really want to keep that snapshot around long enough to
>>>>> copy the entire database?  I bet you don't: if the database is big,
>>>>> holding back xmin for long enough to copy the whole thing isn't likely
>>>>> to be fun.
>>>>
>>>> I can confirm that this would be epic fail, at least for londiste. It takes about 3 weeks for a new copy of a ~2TB
database.There's no way that'd work with one snapshot. (Granted, copy performance in londiste is rather lackluster, but
still...)
>>>
>>> I'd marked this email as todo:
>>> If you have such a huge database you can, with logical decoding at
>>> least, use a basebackup using pg_basebackup or pg_start/stop_backup()
>>> and roll forwards from that... That'll hopefull make such huge copies
>>> much faster.
> 
>> Just keep in mind that one of the use cases for logical replication is upgrades.
> 
> Should still be fine. Make a physical copy; pg_upgrade; catchup via
> logical rep.
> 
Have in mind that it is not an option if you want to copy *part* of the
database(s) (unless you have space available and want to do the cleanup
after upgrade). In a near future, a (new) tool could do (a) copy schema,
(b) accumulate modifications while copying data, (c) copy whole table
and (d) apply modifications for selected table(s)/schema(s). Such a tool
could even be an alternative to pg_upgrade.


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento