Hi Tom, hi Mark,
Tom, thank you for having a look into this!
Tom Lane [2007-03-29 13:49 -0400]:
> Martin Pitt <martin@piware.de> writes:
> > https://launchpad.net/bugs/93042 has symbolic gdb backtraces of all
> > three processes that are involved.
>=20
> 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=20
> 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.
>=20
> 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.
>=20
> 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 pl=
ease
have a look?
Thanks,
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org