Hi, Thanks for the information. The culprit seems to be that we keep a mutex locked for the duration of the COMMIT statement, which seems to take long. This then causes to stop processing the inputs. Is there any reason why PgSQL stalls in COMMIT? Can you check the pgsql side? maybe syslog-ng progresses, just very-very slowly. if for instance COMMIT takes a minute, and then it wakes up processes a message and then a commit again, may make it feel like it completely stopped whereas it stops waiting for long operations. Hmm.. it would probably make sense to release the lock around the commit operation though. -- Bazsi Hello, mine colleague prepared the backtraces. Please, see attached file. Let me know if there is anything elase a should provide (cfg files, logs,..). Thanks for any suggestions/help. -- Tomáš Novosad LinuxBox.cz, s.r.o. 28. října 168, 709 00 Ostrava tel.: +420 591 166 221 mobil: +420 737 238 655 email: tomas.novosad@linuxbox.cz jabber: novosad@linuxbox.cz www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis@linuxbox.cz On 5. 1. 12:11, Scheidler, Balázs wrote:
Hi,
checking the backtrace again, it might actually be a genuine deadlock. can you give a backtrace of all the threads as syslog-ng stalls like that?
-- Bazsi
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq