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

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
Date: 2016-09-05 09:38:46
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 5 September 2016 at 16:33, Petr Jelinek <petr(at)2ndquadrant(dot)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
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-09-05 09:42:52 Re: Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))
Previous Message Craig Ringer 2016-09-05 09:28:02 Re: [PATCH] Send catalog_xmin separately in hot standby feedback