On 14 March 2016 at 17:16, Petr Jelinek <p...@2ndquadrant.com> wrote:

> It will not change the fact that slot can go backwards

Sure. I don't consider that a problem in general though. It's similar to
the way we lose cached sequence chunks on crash - a performance
optimisation with a user visible effect. It needs to be documented
correctly, but isn't IMO a problem.

Failing to save the full slot state on clean shutdown is though, IMO. It
wouldn't matter if it was only used for sync rep, but since it's also used
to manage the resume point for SQL-level logical decoding calls we should
make a reasonable effort to preserve it ... and allow the user to handle
the situation correctly when we fail to preserve it.

> You btw can emulate asking for the specific LSN in SQL interface by first
> calling the pg_logical_slot_get_changes function with upto_lsn set to
> whatever lsn you expect to start at, but it's ugly.


I didn't realise pg_logical_slot_get_changes could backtrack by setting an
upto_lsn in the past. That doesn't seem like something we should really be
doing - if it's a limit, and we're already past that limit, we should just
be returning the empty set.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to