From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Satoshi Nagayasu <snaga(at)uptime(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Michael Paquier <mpaquier(at)vmware(dot)com> |
Subject: | Re: pg_rewind in contrib |
Date: | 2015-01-07 08:27:35 |
Message-ID: | 54ACEDF7.1000909@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/06/2015 10:39 PM, Peter Eisentraut wrote:
> If this ends up shipping, it's going to be a massively popular tool. I
> see it as a companion to pg_basebackup. So it should sort of work the
> same way. One problem is that it doesn't use the replication protocol,
> so the setup is going to be inconsistent with pg_basebackup. Maybe the
> replication protocol could be extended to provide the required data.
> Maybe something as simple as "give me this file" would work.
Yeah, that would be nice. But I think we can live with it as it is for
now, and add that later.
> That might lose the local copy mode, but how important is that?
> pg_basebackup doesn't have that mode. In any case, the documentation
> doesn't explain this distinction. The option documentation is a bit
> short in any case, but it's not clear that you can choose between local
> and remote mode.
Changing the libpq mode to use additional replication protocol commands
would be a localized change to libpq_fetch.c. No need to touch the local
copy mode.
> The test suite should probably be reimplemented in Perl. (I might be
> able to help.) Again, ingenious, but it's very hard to follow the
> sequence of what is being tested. And some Windows person is going to
> complain. ;-)
Yeah, totally agreed.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2015-01-07 09:04:24 | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Previous Message | Heikki Linnakangas | 2015-01-07 08:22:35 | Re: pg_rewind in contrib |