Re: Logical decoding slots can go backwards when used from SQL, docs are wrong

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
Дата
Msg-id 56E68AB6.6000004@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Logical decoding slots can go backwards when used from SQL, docs are wrong  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: Logical decoding slots can go backwards when used from SQL, docs are wrong  (Craig Ringer <craig@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Rahila Syed
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat