Hi Tom, hi Mark, Tom, thank you for having a look into this!
Tom Lane [2007-03-29 13:49 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > https://launchpad.net/bugs/93042 has symbolic gdb backtraces of all > > three processes that are involved. > > Are these really all the processes involved? The createdb process and > the autovac process are both waiting for someone else to give up the > BtreeVacuumLock, but that is never held for any long period, and it's > certainly not held by the guy trying to do InitPostgres. There are more processes, unfortunately I don't have backtraces of them. I got this from my IRC log: 15928 ? Ss 0:00 postgres: mark launchpad_ftest_template [local] CREATE DATABASE 15956 ? Ss 0:00 postgres: session session_dev [local] idle 15957 ? Ss 0:00 postgres: launchpad launchpad_dev [local] idle 15958 ? Ss 0:00 postgres: session session_dev [local] idle 15969 ? Ss 0:00 postgres: launchpad launchpad_dev [local] idle 16014 ? Ss 0:00 postgres: launchpad launchpad_dev [local] idle 16273 ? Ss 0:00 postgres: mark launchpad_ftest_template [local] startup waiting > I believe that the guy trying to do InitPostgres is blocked by the > createdb process --- it looks like he's trying to attach to the same > DB being used as a template for the createdb, and as of 8.2 we lock out > new entries to a template DB until the copy is complete. > > It's possible that this is not a deadlock per se, but the aftermath of > someone having errored out without releasing the BtreeVacuumLock --- but > I don't entirely see how that could happen either, at least not without > a core dump scenario. > > Is there anything in the postmaster log when this happens? Errors out > of _bt_start_vacuum would be particularly interesting... I believe Mark's postgres runs with fully verbose logging. Mark, can you please have a look? Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
