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.
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...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
