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.
>>>
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is definitely a bug (I unfortunately didn't see your message until
>> after I'd replicated your reasoning...) but the word from Shuttleworth
>> is that he doesn't see either of those messages in his postmaster log.
>> So it se
Hi Heikki,
Heikki Linnakangas [2007-03-30 8:57 +0100]:
> Martin: Would it be possible for you to reproduce the problem with a
> patched version?
I cannot reproduce the problem myself, but I can easily build a
package with this patch, hand it to Mark, and ask him to test it.
Thanks a lot!
Mart
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Ok, I think I know what's happening. In btbulkdelete we have a
PG_TRY-CATCH block. In the try-block, we call _bt_start_vacuum which
acquires and releases the BtreeVacuumLock. Under certain error
conditions, _bt_start_vacuum calls e
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Ok, I think I know what's happening. In btbulkdelete we have a
> PG_TRY-CATCH block. In the try-block, we call _bt_start_vacuum which
> acquires and releases the BtreeVacuumLock. Under certain error
> conditions, _bt_start_vacuum calls elog(ERROR)
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
I wrote:
> 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.
On closer inspection, the autovac stack tra
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
BtreeVacuum
Martin Pitt wrote:
Since our Launchpad developers switched from 8.1 to 8.2.3, they often
encounter a situation when the postmaster gets stuck and needs to be
restarted. This happens on various CREATE commands (FUNCTION,
DATABASE, not consistently).
The backtraces show that the process doing the
Martin Pitt wrote:
Since our Launchpad developers switched from 8.1 to 8.2.3, they often
encounter a situation when the postmaster gets stuck and needs to be
restarted. This happens on various CREATE commands (FUNCTION,
DATABASE, not consistently).
The backtraces show that the process doing the
Hi,
Since our Launchpad developers switched from 8.1 to 8.2.3, they often
encounter a situation when the postmaster gets stuck and needs to be
restarted. This happens on various CREATE commands (FUNCTION,
DATABASE, not consistently).
The backtraces show that the process doing the CREATION, anothe
11 matches
Mail list logo
