Re: [HACKERS] Logical replication in the same cluster

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Logical replication in the same cluster
Дата
Msg-id CAB7nPqQxyFPwED0DGvOM4Mc48Vv21CJBZsLtpV8iw0SokeVarg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Logical replication in the same cluster  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Logical replication in the same cluster
Список pgsql-hackers
On Thu, Apr 27, 2017 at 7:02 AM, Tom Lane <tgl@sss.pgh.pa.us> 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"?

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.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins
Следующее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Fixup some misusage of appendStringInfo and friends