Re: pg_terminate_backend idea - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_terminate_backend idea
Date
Msg-id 200506242115.j5OLFcb01754@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_terminate_backend idea  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_terminate_backend idea
List pgsql-hackers
Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Assuming we don't get such a case, and a chance to fix it, before 8.1
> > (while still hoping we will get it fixed properly, we can't be sure, can
> > we? If we were, it'd be fixed already). In this case, will you consider
> > such a kludgy solution as a temporary fix to resolve a problem that a
> > lot of users are having? And then plan to have it removed once sending
> > SIGTERM directly to a backend can be considered safe?
>
> Kluges tend to become institutionalized, so my reaction is "no".  It's
> also worth pointing out that with so little understanding of the problem
> Rod is reporting, it's tough to make a convincing case that this kluge
> will avoid it.  SIGTERM exit *shouldn't* be leaving any corrupted
> locktable entries behind; it's not that much different from the normal
> case.  Until we find out what's going on, introducing still another exit
> path isn't really going to make me feel more comfortable, no matter how
> close it's alleged to be to the normal path.

I have been running some tests to try to see the lock table corruption
but I have been unable to reproduce the problem.  I have attached my
crude test scripts.  I would run the scripts and then open another
session as a different user and do UPDATE and LOCK to cause the psql
session to block.

The only functional difference I can see between a SIGTERM exit and a
cancel followed by a normal exit is the call to
AbortCurrentTransaction().  Could that be significant?  Because I can't
reproduce the failure I can't know for sure.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#!/usr/contrib/bin/expect --
set timeout -1
eval spawn sql test
expect -nocase "test=>"
send "begin;\r"
expect -nocase "test=>"
send "lock pg_class;\r"
expect -nocase "test=>"
send "select * from pg_locks;\r"
expect -nocase "test=>"
send "update test set x=3;\r"
expect -nocase "test=>"
expect eof
exit
while :
do
    XPID=`/letc/ps_sysv -ef | grep 'postgres test'|grep -v grep|awk '{print $2}'`
    if [ "$XPID" != "" ]
    then    kill $XPID
        echo $XPID
        XPID=`/letc/ps_sysv -ef | grep 'psql test'|grep -v execargs|awk '{print $2}'`
        kill $XPID
    fi
    sleep 1
done

pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: DBSize backend integration
Next
From: Tom Lane
Date:
Subject: Re: pg_terminate_backend idea