From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> |
Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: [HACKERS] Issues with logical replication |
Date: | 2018-01-03 17:47:10 |
Message-ID: | 20180103174710.lwutjgidhoqbzgay@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stas Kelvich wrote:
> Seems that having busy loop is the best idea out of several discussed.
>
> I thought about small sleep at the bottom of that loop if we reached topmost
> transaction, but taking into account low probability of that event may be
> it is faster to do just busy wait.
In other locations where we do similar things we have 1ms sleeps. I
agree with the need for a comment here.
Proposed patch attached. I tried your reload.pgb test case in 9.4
(after changing pgoutput to test_decoding and removing the 3rd arg to a
function call) and the crash takes about 3 seconds without patch in my
machine. No crash with this patch.
Will push this shortly after lunch.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Make-XactLockTableWait-work-for-transactions-that-ar.patch | text/plain | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-01-03 17:49:39 | Re: Speeding up pg_upgrade |
Previous Message | Tom Lane | 2018-01-03 17:37:24 | Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr |