Re: Handle PGRES_COPY_BOTH in psql for logical replication?

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Handle PGRES_COPY_BOTH in psql for logical replication?
Date: 2015-06-05 08:59:33
Message-ID: CACACo5SDXkmw45XB2djb9_cvjBosDkDa0qJiaKA9CM4M0eOtvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 5, 2015 at 10:22 AM, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-06-05 09:45:09 Re: Multixid hindsight design
Previous Message Andres Freund 2015-06-05 08:22:42 Re: Handle PGRES_COPY_BOTH in psql for logical replication?