unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
* 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 inbox:

	../../../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).