On 5 September 2016 at 16:33, Petr Jelinek <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
