* unblock function in pg messes up with unicorn
@ 2013-12-06 12:29 Sam Saffron
2013-12-06 18:48 ` Eric Wong
0 siblings, 1 reply; 3+ messages in thread
From: Sam Saffron @ 2013-12-06 12:29 UTC (permalink / raw)
To: mongrel-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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: unblock function in pg messes up with unicorn
2013-12-06 12:29 unblock function in pg messes up with unicorn Sam Saffron
@ 2013-12-06 18:48 ` Eric Wong
2013-12-07 0:04 ` Sam Saffron
0 siblings, 1 reply; 3+ messages in thread
From: Eric Wong @ 2013-12-06 18:48 UTC (permalink / raw)
To: unicorn list
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: unblock function in pg messes up with unicorn
2013-12-06 18:48 ` Eric Wong
@ 2013-12-07 0:04 ` Sam Saffron
0 siblings, 0 replies; 3+ messages in thread
From: Sam Saffron @ 2013-12-07 0:04 UTC (permalink / raw)
To: unicorn list
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-12-07 0:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-06 12:29 unblock function in pg messes up with unicorn Sam Saffron
2013-12-06 18:48 ` Eric Wong
2013-12-07 0:04 ` Sam Saffron
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).