| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, 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-04-27 01:25:38 |
| Message-ID: | 8dac43a3-3d0d-ceeb-7dd1-7fb67db3826f@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/26/17 19:18, Michael Paquier wrote:
>> 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"?
>
> Perhaps using some detection with the replication origins? Just an
> instinctive idea.. The current behavior is confusing for users, I have
> fallen into this trap a couple of times already.
We had some discussions early on about detecting connections to the same
server, but it's not entirely clear how to do that and it didn't seem
worth it at the time.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-04-27 01:30:54 | Re: Declarative partitioning - another take |
| Previous Message | Peter Eisentraut | 2017-04-27 01:13:29 | Re: Fix a typo in worker.c |