Re: Logical decoding slots can go backwards when used from SQL, docs are wrong - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
Date
Msg-id 56E68AB6.6000004@2ndquadrant.com
Whole thread Raw
In response to Re: Logical decoding slots can go backwards when used from SQL, docs are wrong  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
List pgsql-hackers
On 14/03/16 10:48, Craig Ringer wrote:
>
>     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.
>

Not past, future from the point of old confirmed_lsn at least. The point 
was that the next call will start from whatever lsn you specified as 
upto_lsn.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Rahila Syed
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Ashutosh Bapat
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat