require 'pg'
conn = PG.connect(dbname: 'meta')
trap 'USR1' do
puts "YAY"
end
Thread.new do
sleep 0.1
Process.kill("USR1", Process.pid)
end
sleep 1
puts "HERE"
Thread.new do
sleep 0.1
Process.kill("USR1", Process.pid)
end
conn.exec("select pg_sleep(10)")
sam@ubuntu:~/Source$ ruby test2.rb
YAY
HERE
YAY
test2.rb:27:in `exec': ERROR: canceling statement due to user request
(PG::QueryCanceled)
from test2.rb:27:in `<main>'
this is the ubf defined inside pg.
void ubf_cancel_running_command(void *c)
{
/*
has no idea why it was interrupted, should it stop the query due to USR1
*/
PGconn *conn = (PGconn*) c;
PQrequestCancel(conn);
}
This leaves a bunch of questions:
1. Is this a pg bug? How could they even implement a ubf in such a way
that it does not stop queries when signals are sent? The main issue is
that without this Thread.kill will have to wait for queries to finish.
2. Is this a ruby bug? should there be a more sophisticated protocol
here? Should trap handlers inform the runtime that a ubf is not
needed?
something else ?
Similar issue exists in mysql afaik.
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
