Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we on this?
>
> Still trying to think of a less messy solution...
OK, put in the patches hold queue for 8.4.
---
>
> >> What it essentially says is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where are we on this?
Still trying to think of a less messy solution...
>> What it essentially says is that trying to clean up shared-memory
>> state in a PG_TRY block is unsafe: you can't be certain you'll
>> get to do it.
rega
Where are we on this?
---
Tom Lane wrote:
> In this thread:
> http://archives.postgresql.org/pgsql-bugs/2007-03/msg00145.php
> we eventually determined that the reported lockup had three components:
>
> (1) something (still
Jim Nasby wrote:
> On Apr 11, 2007, at 6:23 PM, Jim Nasby wrote:
>> FWIW, you might want to put some safeguards in there so that you don't
>> try to inadvertently kill the backend that's running that function...
>> unfortunately I don't think there's a built-in function to tell you
>> the PID of th
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> AFAICS, there are basically two ways we might try to approach this:
>>
>> Plan A: establish the rule that you mustn't try to clean up shared
>> memory state in a PG_CATCH block. Anything you need to do like that
>> has to be
On Apr 11, 2007, at 6:23 PM, Jim Nasby wrote:
FWIW, you might want to put some safeguards in there so that you
don't try to inadvertently kill the backend that's running that
function... unfortunately I don't think there's a built-in function
to tell you the PID of the backend you're connect
Tom Lane wrote:
2) if a SIGTERM happens to arrive while btbulkdelete is running,
the next CHECK_FOR_INTERRUPTS will do elog(FATAL), causing elog.c
to do proc_exit(0), leaving the vacuum still recorded as active in
the shared memory array maintained by _bt_start_vacuum/_bt_end_vacuum.
The PG_TRY b
FWIW, you might want to put some safeguards in there so that you
don't try to inadvertently kill the backend that's running that
function... unfortunately I don't think there's a built-in function
to tell you the PID of the backend you're connected to; if you're
connecting via TCP you could
Tom Lane wrote:
> Stuart Bishop <[EMAIL PROTECTED]> writes:
>
>> After a test is run, the test harness kills any outstanding connections so
>> we can drop the test database. Without this, a failing test could leave open
>> connections dangling causing the drop database to block.
>>
>
> Just
Tom Lane wrote:
> Stuart Bishop <[EMAIL PROTECTED]> writes:
>> After a test is run, the test harness kills any outstanding connections so
>> we can drop the test database. Without this, a failing test could leave open
>> connections dangling causing the drop database to block.
>
> Just to make it
Stuart Bishop <[EMAIL PROTECTED]> writes:
> After a test is run, the test harness kills any outstanding connections so
> we can drop the test database. Without this, a failing test could leave open
> connections dangling causing the drop database to block.
Just to make it perfectly clear: we don't
Mark Shuttleworth wrote:
> Tom Lane wrote:
>> (1) something (still not sure what --- Martin and Mark, I'd really like
>> to know) was issuing random SIGTERMs to various postgres processes
>> including autovacuum.
>>
>
> This may be a misfeature in our test harness - I'll ask Stuart Bishop to
>
Tom Lane wrote:
> (1) something (still not sure what --- Martin and Mark, I'd really like
> to know) was issuing random SIGTERMs to various postgres processes
> including autovacuum.
>
This may be a misfeature in our test harness - I'll ask Stuart Bishop to
comment.
Mark
In this thread:
http://archives.postgresql.org/pgsql-bugs/2007-03/msg00145.php
we eventually determined that the reported lockup had three components:
(1) something (still not sure what --- Martin and Mark, I'd really like
to know) was issuing random SIGTERMs to various postgres processes
includin
14 matches
Mail list logo
