| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical replication: stuck spinlock at ReplicationSlotRelease |
| Date: | 2017-06-23 20:50:57 |
| Message-ID: | 9128.1498251057@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 6/23/17 13:26, Alvaro Herrera wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> I can reproduce the issue with --client-min-messages=debug2 or debug1,
> but it doesn't appear with the default settings. I don't always get the
> "stuck spinlock" message, but it hangs badly pretty reliably after two
> or three rounds of erroring.
> Removing the call you pointed out doesn't make a difference, but it's
> possibly something similar.
Maybe some function invoked in a debug ereport accesses shared memory
or takes locks (eg, for catalog access)?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-06-23 22:20:20 | Re: initdb initalization failure for collation "ja_JP" |
| Previous Message | Tom Lane | 2017-06-23 20:38:42 | Re: initdb initalization failure for collation "ja_JP" |