Re: pg_rewind in contrib

On 2015-01-06 15:39:29 -0500, Peter Eisentraut wrote:
> I applaud the ingenuity on all levels in this patch. But it seems to me
> that there is way too much backend knowledge encoded and/or duplicated
> in a front-end program.

Hm. There's really not that much in the current version anymore? Sure,
there's some xlog record specific knowledge, some about the whole data
directory layout and a bunch of timeline specific stuff. But that's not
that much.

Don't get me wrong - I personally think this shouldn't be in contrib but
in bin. The amount of prerequisite work to allow this to be
maintainable (2c03216d, 2076db2, ...) is a hint of how closely this is
linked and how much effort core community people have put into this. I
don't think contrib/ is the right place for that. Even though we haven't
found something we can agree on wrt moving other stuff (apprently at
least?) from contrib, we can still place new stuff in src/bin instead of
contrib.

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.

> 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.

> 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?

> 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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services