Re: Timeline following for logical slots

 

(Patch attached. Blah blah explanation blah):

The way I've written things the endpos is the point where we stop receiving and exit, so if a record with start lsn >= endpos is received we'll exit without writing it.

I thought about writing out the record before exiting if the record start LSN is exactly endpos. That'd be handy in cases where the client knows a commit's LSN and wants everything up to that commit. But it's easy enough in this case for the client to set endpos to the commit start lsn + 1, so it's not like the current behaviour stops you doing anything, and it means the code can just test endpos and exit. pg_current_xlog_insert_location() will return at least the lsn of the last commit + 1, so you'll get the expected behaviour for free there. It does mean we might wait for the next walsender keepalive or status update before we exit, though, so if someone feels strongly that endpos should be an inclusive bound I can do that. It's just a bit uglier in the code.

I can't add a "number of xacts" filter like the SQL interface has because pg_recvlogical has no idea which records represent a commit, so it's not possible without changing the protocol. I'm not convinced a "number of messages" filter is particularly useful. I could add a timeout, but it's easy enough to do that in a wrapper (like IPC::Run). So I'm sticking with just the LSN filter for now.

Also because pg_recvlogical isn't aware of transaction boundaries, setting endpos might result in a partial transaction being output if endpos is after the end of the last xact wanted and some other xact containing changes made before endpos commits after endpos but before the next status update/keepalive is sent. That xact won't be consumed from the server and will just be sent when the slot is next read from. This won't result in unpredictable output for testing since there we control what other xacts run and will generally exit based on walsender status updates/keepalives.