Martin Pitt wrote: > 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? >
Yes, we run with lots of logging, what can I send you that would help? In this case I think I've probably drowned the relevant stuff in noise, but assuming the autovaccum=off change does not stop it from happening again, I will know what to send you when it re-occurs. This sort of "getting stuck" has been happening pretty consistently for me with out test suite and pg8.2. The test suite does a lot of DB creation, hammering, tearing down and then creation again. Mark
