Re: hung backends stuck in spinlock heavy endless loop
От | Andres Freund |
---|---|
Тема | Re: hung backends stuck in spinlock heavy endless loop |
Дата | |
Msg-id | 20150114001110.GE5245@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: hung backends stuck in spinlock heavy endless loop (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2015-01-13 19:05:10 -0500, Tom Lane wrote: > Merlin Moncure <mmoncure@gmail.com> writes: > > On Tue, Jan 13, 2015 at 5:54 PM, Peter Geoghegan <pg@heroku.com> wrote: > >> In case it isn't clear, I think that the proximate cause here may well > >> be either one (or both) of commits > >> efada2b8e920adfdf7418862e939925d2acd1b89 and/or > >> 40dae7ec537c5619fc93ad602c62f37be786d161. Probably the latter. I think > >> that the profile is roughly consistent with that, although I may well > >> be wrong. > > > I'm out of time for the day, but I'm fairly confident I can reproduce. > > I'll see if I can reverse those commits tomorrow and retest (I'm on > > development box). > > I'm not convinced that Peter is barking up the right tree. I'm noticing > that the profiles seem rather skewed towards parser/planner work; so I > suspect the contention is probably on access to system catalogs. No > idea exactly why though. The plan contains plpgsql and exec_stmt_dynexecute(). So it might just be executing crazy amounts of dynamic statements. I'm still wondering if this isn'ta different issue to the first one, the plans do look different. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: