Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
От | Craig Ringer |
---|---|
Тема | Re: Logical decoding slots can go backwards when used from SQL, docs are wrong |
Дата | |
Msg-id | CAMsr+YEk3QH0OeO4TzL8=FsdUYc9mCxdEXZ_NkgMXL01VDcj8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical decoding slots can go backwards when used from SQL, docs are wrong (Petr Jelinek <petr@2ndquadrant.com>) |
Список | pgsql-hackers |
On 5 September 2016 at 16:33, Petr Jelinek <petr@2ndquadrant.com> wrote: >> The better alternative is to add a variant on >> pg_logical_slot_get_changes(...) etc that accepts a start LSN. But >> it's not convenient or easy for SQL callers to extract the last commit >> LSN received from the last call to pass it to the next one, so this >> isn't simple, and is probably best tackled as part of the SQL >> interface API change Petr and Andres discussed in this thread. >> > > It isn't? I thought lsn is first column of the output of that function? It is. While it's a pain to use that from SQL (psql, etc) as well as doing something with the results, there's no point since anything working in simple SQL will get terminated when the server restarts anyway. So really my point above is moot. That's doesn't reflect on the slot dirty patch, it just means there's no need to do anything extra when we add the cursor-like interface later in order to fully solve this. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: