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 - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
Sam Saffron <sam.saffron@gmail.com> wrote:> 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.No, not a pg bug. pg needs to account for the user hitting Ctrl-C and wanting to cancel a query (oh-no-I-started-DELETE-without-WHERE!).> 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?I don''t know. Something like: trap(:QUIT, no_ubf: true) { ... } ?> something else ?Also see http://mid.gmane.org/20131120094717.GA17836@dcvr.yhbt.net Btw, given the master <-> worker separation in unicorn, we can also have the master talk to the worker through a pipe and avoid signals between the two.> Similar issue exists in mysql afaik.I don''t think the mysql2 gem currently interrupts running queries. Not sure about the others. _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
yeah, mysql appears to be using the default ubf which simply forces your thread to be scheduled https://github.com/brianmario/mysql2/blob/a9787cbb88f18d12f0b5c370c519d077ad68c862/ext/mysql2/result.c#L203 I think it would be cool to change unicorn to perform all the master / worker coordination via pipes, only caveat is that QUIT and USR1 on workers will still not work as expected if using the pg gem. I am not sure Something like trap(:QUIT, no_ubf: true) would fly with core but I can raise a ticket on redmine and see what people think. On Sat, Dec 7, 2013 at 5:48 AM, Eric Wong <normalperson@yhbt.net> wrote:> Sam Saffron <sam.saffron@gmail.com> wrote: >> 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. > > No, not a pg bug. pg needs to account for the user hitting Ctrl-C and > wanting to cancel a query (oh-no-I-started-DELETE-without-WHERE!). > >> 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? > > I don''t know. Something like: trap(:QUIT, no_ubf: true) { ... } ? > >> something else ? > > Also see http://mid.gmane.org/20131120094717.GA17836@dcvr.yhbt.net > > Btw, given the master <-> worker separation in unicorn, we can also > have the master talk to the worker through a pipe and avoid signals > between the two. > >> Similar issue exists in mysql afaik. > > I don''t think the mysql2 gem currently interrupts running queries. > Not sure about the others. > _______________________________________________ > Unicorn mailing list - mongrel-unicorn@rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying_______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying