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. Ugh. 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
