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 not
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.
regards, tom
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 that
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
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
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 handled by an
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 the
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
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 perfectly
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
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
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
comment.
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
13 matches
Mail list logo
