Re: [HACKERS] Function to move the position of a replication slot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Function to move the position of a replication slot
Date
Msg-id 30436.1502921685@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Function to move the position of a replication slot  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Function to move the position of a replication slot  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Function to move the position of a replication slot  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-08-16 17:06:42 -0400, Tom Lane wrote:
>> 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.

+1 for constraining it like that, but I don't think that's an argument
against using "move" or "change" as the verb.  I don't like "forward"
because that's not the right word.  The only verb senses of "forward"
in my Mac's dictionary are "send a message on to a further destination"
and "help to advance or promote" (the latter usage is pretty obscure IMO).
Neither one seems applicable here.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Function to move the position of a replication slot