pg_basebackup vs WAL fetching

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: pg_basebackup vs WAL fetching
Date: 2016-02-12 14:37:05
Message-ID: CABUevEy6bHc96npyOVRdR=zHhYU-4sFtCdayAu74XBY2BrJN1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Right now, pg_basebackup can only use replication slots with WAL streaming.
It's intended, I believe, to be used when you use pg_basebackup to set up a
new replica, to close the gap before starting a replica (ref
http://www.postgresql.org/message-id/flat/555DD2B2(dot)7020000(at)gmx(dot)net).

A bit down that thread there is a discussion about pg_basebackup being able
to use this for standalone backups, specifically -X mode, to make sure
things are not rotated away.

AFAICT this was never done, with the thread ending on a subject of "this is
for a different thread". I couldn't find such a different thread.

I think it would still be a very useful feature. In fact, I think it would
be useful enough that it should be enabled by default (but of course
possible to turn off), in the interest of making the default more difficult
to break.

On the backend side, I think that would just mean adding a parameter
to CREATE_REPLICATION_SLOT
to create the slot ephemeral. And register an exit handler that will remove
it when the backup session disconnects as well (ephemeral slots go away on
crash, but AIUI not on regular shutdown).

With this, it should be useful for both -X fetch and -X stream, as long as
pg_basebackup doesn't connect from the master until it has seen all it's
WAL.

Did I miss a thread somewhere saying this is not a good idea?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-12 14:39:20 Re: GinPageIs* don't actually return a boolean
Previous Message Robert Haas 2016-02-12 14:30:02 Re: Patch: fix lock contention for HASHHDR.mutex