Re: [HACKERS] Logical replication in the same cluster - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: [HACKERS] Logical replication in the same cluster
Date
Msg-id A737B7A37273E048B164557ADEF4A58B53A5C9B5@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Re: [HACKERS] Logical replication in the same cluster  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs.  My server logs say:
> 
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worked around by
>> creating the slot manually via the SQL interface for example and create
>> the subscription using WITH (NOCREATE SLOT, SLOT NAME = 'your slot') .
> 
> If that's a predictable deadlock, I think a minimum expectation is that
> the system should notice it and throw an error, not just hang.  (Then
> the error could give a hint about how to work around it.)  But the case
> Bruce has in mind doesn't seem like a crazy use-case to me.  Can't we
> make it "just work"?

+1

I think that many people who start experimenting with logical replication
will run into this (like I did).

If nothing else, it's bad PR.
People will get the first impression that logical replication doesn't
work well.

Yours,
Laurenz Albe

pgsql-hackers by date:

Previous
From: Remi Colinet
Date:
Subject: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of longrunning SQL queries/utilities
Next
From: Yugo Nagata
Date:
Subject: Re: [HACKERS] Incorrect documentation about pg_stat_activity