From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, <heikki(dot)linnakangas(at)iki(dot)fi> |
Subject: | Re: Using pg_rewind for differential backup |
Date: | 2014-11-28 07:49:55 |
Message-ID: | 54782923.6010503@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/28/2014 09:30 AM, Michael Paquier wrote:
> On Thu, Nov 27, 2014 at 9:39 PM, Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com>
> wrote:
>
>> Can we tweak pg_rewind to take differential backups in PostgreSQL?
>> I was wondering can we hack the pg_rewind code to print the details of the
>> file which have been modified compared to a target server. The list output
>> can then be used for taking differential backups.
>>
>> Or perhaps we can add an option/switch in pg_rewind --action
>>
>> --action=print ---> would print the files which have changed
>> --action=sync ---> would sync them
>> --action=copy ---> with this option I can specify an additional optino
>> --target-dir where I can copy the files which have changed
>>
>
> This discussion is not really adapted on hackers as pg_rewind is not
> included in Postgres core code. Please let's discuss your proposal there.
> Btw, pg_rewind is not aimed to be used as a tool for a backup facility. You
> may find easier to use existing backup solutions instead, or help out with
> an in-core solution.
It also would be quite straightforward to write a separate tool to do
just that. Would be better than conflating pg_rewind with this. You
could use pg_rewind as the basis for it - it's under the same license as
PostgreSQL.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2014-11-28 08:38:00 | Re: Marginal performance improvement: replace bms_first_member loops |
Previous Message | Heikki Linnakangas | 2014-11-28 07:43:29 | Re: Allocation in critical section after node exits archive recovery |