Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 3/11/16 1:11 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >>> It looks like a decision needs to be made here whether to apply this patch, >>> send it back to the author, or reject it so I'm marking it "Ready for >>> Committer". >>> >>> Robe

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

Robert Haas writes: > On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >> It looks like a decision needs to be made here whether to apply this patch, >> send it back to the author, or reject it so I'm marking it "Ready for >> Committer". >> >> Robert, since you were participating in this co

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: > It looks like a decision needs to be made here whether to apply this patch, > send it back to the author, or reject it so I'm marking it "Ready for > Committer". > > Robert, since you were participating in this conversation can you have a > l

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 1/21/16 9:53 AM, Shulgin, Oleksandr wrote: > On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas > wrote: > > > So it's true that the client can't unilaterally terminate COPY BOTH > mode; it can only send CopyDone. But an error on the server side > should do

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas wrote: > On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer > wrote: > > It enters COPY BOTH mode before it invokes the startup callback. The > client > > has no way to unilaterally terminate COPY BOTH mode and return to the > normal > > walsender protocol

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer wrote: > It enters COPY BOTH mode before it invokes the startup callback. The client > has no way to unilaterally terminate COPY BOTH mode and return to the normal > walsender protocol. The server doesn't do it when there's an ERROR. So the > only opti

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 20 January 2016 at 15:28, Craig Ringer wrote: > > For that reason I'd actually like to enter COPY BOTH mode before the > startup callback, as is currently the case. So I'd like to wrap the > decoding startup callback in a PG_TRY that catches an ERROR raised by the > startup callback (if any) a

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 5 January 2016 at 18:35, Shulgin, Oleksandr wrote: > psycopg2test=# START_REPLICATION SLOT "test1" LOGICAL 0/0 ("invalid" >> 'value'); >> unexpected PQresultStatus: 8 >> > I think the point here is that START_REPLICATION issues useful errors and returns to the normal protocol up until the log

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Tue, Jan 5, 2016 at 11:35 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> >> I didn't look in the code yet, but if someone knows off top of the head >> the reason to this behavior,

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > Hackers, > > It looks like there's an inconsistency in error handling during > START_REPLICATION command of replication protocol: > > $ psql postgres://localhost/psycopg2test?replication=database > psql (9

[HACKERS] Inconsistent error handling in START_REPLICATION command

Hackers, It looks like there's an inconsistency in error handling during START_REPLICATION command of replication protocol: $ psql postgres://localhost/psycopg2test?replication=database psql (9.6devel) Type "help" for help. psycopg2test=# IDENTIFY_SYSTEM; systemid | timeline | xlogp