From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | 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:06:53 |
Message-ID: | 54ACE91D.1020904@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/07/2015 02:17 AM, Andres Freund wrote:
> On 2015-01-06 15:39:29 -0500, Peter Eisentraut wrote:
> It wouldn't hurt if we could share SimpleXLogPageRead() between
> pg_xlogdump and pg_rewind as the differences are more or less
> superficial, but that seems simple enough to achieve by putting a
> frontend variant in xlogreader.c/h.
It's not that much code. And although they're almost identical now, it's
not clear that pg_rewind and pg_xlogdump would want the same behaviour
in the future. pg_rewind might want to read files from a WAL archive,
for example. (Not that I have any plans for that right now)
>> 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.
>
> I'm not particularly bothered by the requirement of also requiring a
> normal, not replication, connection. In most cases that'll already be
> allowed.
Yeah, it's not a big problem in practice, but it sure would be nice for
usability if it wasn't required. One less thing to document and prepare for.
>> Maybe something as simple as "give me this file" would work.
>
> Well, looking at libpq_fetch.c it seems there'd be a bit more required.
>
> Not having to create a temporary table on the other side would be nice -
> afaics there's otherwise not much stopping this from working against a
> standby?
Hmm, that could be done. The temporary table is convenient, but it could
be refactored to work without it.
>> That might lose the local copy mode, but how important is that?
>> pg_basebackup doesn't have that mode.
>
> But we have plain pg_start/stop_backup for that case. That alternative
> doesn't really exist here.
Also, the local mode works when the server is shut down. The
pg_basebackup analogue of that is just "cp -a $PGDATA backup".
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-01-07 08:22:35 | Re: pg_rewind in contrib |
Previous Message | Ashutosh Bapat | 2015-01-07 07:16:00 | Re: Transactions involving multiple postgres foreign servers |