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 <martin@piware.de> 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
