Re: Handle PGRES_COPY_BOTH in psql for logical replication? - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: Handle PGRES_COPY_BOTH in psql for logical replication?
Date
Msg-id CACACo5SDXkmw45XB2djb9_cvjBosDkDa0qJiaKA9CM4M0eOtvA@mail.gmail.com
Whole thread Raw
In response to Re: Handle PGRES_COPY_BOTH in psql for logical replication?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Jun 5, 2015 at 10:22 AM, Andres Freund <andres@anarazel.de> wrote:
>
> Maybe I'm missing something, which functions do you have in mind exactly?

pg_logical_slot_get_changes() etc?

Oh, totally forgot about these.  However there are two significant differences between using the functions and using START_REPLICATION command:

1. With get/peek_changes one cannot specify start_lsn. A parameter upto_lsn is supported instead.
2. The functions return when either of the upto_* limits is reached or there are no more data to decode, while with internal command it should wait for more data until interrupted by user.

Anyway, using pg_recvlogical is perfectly fine by me, it's just psql can pass the command, but is not ready to handle the request.  Maybe just having are more sensible error message for PGRES_COPY_BOTH is the way to go.

--
Alex

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Handle PGRES_COPY_BOTH in psql for logical replication?
Next
From: Simon Riggs
Date:
Subject: Re: Multixid hindsight design