Re: Logical replication in the same cluster

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Tom Lane *EXTERN*'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical replication in the same cluster
Date: 2017-06-21 14:05:35
Message-ID: A737B7A37273E048B164557ADEF4A58B53A5C9B5@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2017-06-21 14:15:38 Re: Incorrect documentation about pg_stat_activity
Previous Message Remi Colinet 2017-06-21 14:01:14 [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities