Re: Function to control physical replication slot

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to control physical replication slot
Date: 2017-04-13 09:44:13
Message-ID: CABUevExZ2kmARTo5ZHUF20T0zeTYpmG+YHNVPtgsH4ne-i-zgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 13, 2017 at 2:40 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2017-04-12 20:15:52 -0400, Peter Eisentraut wrote:
> > On 4/11/17 05:15, Magnus Hagander wrote:
> > > Is there a particular reason we don't have a function to *set* the
> > > restart_lsn of a replication slot, other than to drop it and recreate
> it?
> >
> > I suppose there could be lots of problems if the LSN you specify isn't
> > valid. And it might be hard to determine whether a given LSN is valid.
>
> As long as we're only talking about the LSN of a physical slot (and not
> the xmin) I'm not sure it's that important that it's valid, as long as
> it's not in the future. But we could otherwise pretty easily assert
> that the new value has to be old_value <= new_value <=
> GetRedoRecPtr()/GetFlushRecPtr(). That should be sufficient for both of
> your use-cases afaics?
>

Yes, I think making that restriction falls well within my requirements --
move it only forward, and not past the end of the current position.

One could argue that a reasonable thing to do when trying to move past the
current position would be to just "truncate" it to the current position,
instead of throwing an error. But that could also be done in userspace
using CASE on the parameter I guess. Not sure which is best. Any opinions
on that?

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Golovanov 2017-04-13 10:04:54 Re: [HACKERS] WIP: [[Parallel] Shared] Hash
Previous Message Kyotaro HORIGUCHI 2017-04-13 09:42:19 Re: WAL logging problem in 9.4.3?