From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Function to move the position of a replication slot |
Date: | 2017-08-16 21:55:12 |
Message-ID: | 20170816215512.c6t7emuj22f7jkgu@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-08-16 17:06:42 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-08-16 12:24:11 -0400, Peter Eisentraut wrote:
> >> On 5/4/17 08:05, Magnus Hagander wrote:
> >>> PFA a patch that adds a new function, pg_move_replication_slot, that
> >>> makes it possible to move the location of a replication slot without
> >>> actually consuming all the WAL on it.
>
> >> The name keeps confusing me. I understand "move" to be "rename" or
> >> possibly "move it elsewhere", but not "move around in". I understand
> >> that there is an analogy with FETCH/MOVE in cursors, but it's still
> >> confusing.
>
> > pg_forward_replication_slot()?
>
> If I understand what this is meant to do, maybe better
> pg_move_replication_slot_lsn() or pg_change_replication_slot_lsn() ?
> The point being that you're adjusting the LSN pointer contained
> in the slot, which is distinct from the slot itself.
I think we should constrain the API to only allow later LSNs than
currently in the slot, rather than arbitrary ones. That's why I was
thinking of "forward". I'm not convinced it's a good / safe idea to
allow arbitrary values to be set.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-16 21:58:41 | Re: Hash Functions |
Previous Message | Heikki Linnakangas | 2017-08-16 21:50:25 | Re: Atomics for heap_parallelscan_nextpage() |