| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical replication: stuck spinlock at ReplicationSlotRelease |
| Date: | 2017-06-23 23:36:25 |
| Message-ID: | 28c6bd45-13f4-9244-7d1a-c1e80fd33ae9@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/23/17 16:10, Peter Eisentraut wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> Removing the call you pointed out doesn't make a difference, but it's
> possibly something similar.
Correction: The fault actually is in that function. I had only looked
at the "if" branch, but it was the "else" branch that triggered the
problem in this run. If I remove those elog calls, everything works
smoothly.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2017-06-23 23:43:35 | Re: pg_terminate_backend can terminate background workers and autovacuum launchers |
| Previous Message | Thomas Munro | 2017-06-23 23:32:33 | Re: Small bug in replication lag tracking |