unblock function in pg messes up with unicorn
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
Re: unblock function in pg messes up with unicorn
Sam Saffron sam.saff...@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.ga17...@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
Re: unblock function in pg messes up with unicorn
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 normalper...@yhbt.net wrote:
Sam Saffron sam.saff...@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.ga17...@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
