Re: [HACKERS] [Glue] Deadlock bug
On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson j...@gluefinance.com wrote: If the locking logic would be modified to allow process 2 to go through, and instead abort process 1, I understand some other scenarios would of course be affected, where the situation would be handled in a less optimal way. Which process dies when there's a deadlock is pretty much arbitary. The first process to notice the deadlock will just throw an error itself. Which one notices first depends on the timing of when the blocking locks were taken. If the second process to get stuck blocks before the first process checks then the first process will notice first. If it does other stuff first then the first process will check, not find a deadlock and go back to sleep. Then the deadlock won't be detected until the second process checks. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Glue] Deadlock bug
OK. Thanks for the explanation. It's probably the case in general, but in all of my tests (10), process 2 always aborts. I don't think it is arbitrary in this example, or could it be? 2010/8/20 Greg Stark gsst...@mit.edu On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson j...@gluefinance.com wrote: If the locking logic would be modified to allow process 2 to go through, and instead abort process 1, I understand some other scenarios would of course be affected, where the situation would be handled in a less optimal way. Which process dies when there's a deadlock is pretty much arbitary. The first process to notice the deadlock will just throw an error itself. Which one notices first depends on the timing of when the blocking locks were taken. If the second process to get stuck blocks before the first process checks then the first process will notice first. If it does other stuff first then the first process will check, not find a deadlock and go back to sleep. Then the deadlock won't be detected until the second process checks. -- greg -- Best regards, Joel Jacobson Glue Finance E: j...@gluefinance.com T: +46 70 360 38 01 Postal address: Glue Finance AB Box 549 114 11 Stockholm Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden
Re: [HACKERS] [Glue] Deadlock bug
On Fri, Aug 20, 2010 at 7:57 PM, Joel Jacobson j...@gluefinance.com wrote: OK. Thanks for the explanation. It's probably the case in general, but in all of my tests (10), process 2 always aborts. I don't think it is arbitrary in this example, or could it be? Well, note the part where I said if it does other stuff first. It's arbitrary in that it depends on the timing in ways that aren't obvious. If you're doing the same thing every time you'll trigger the same arbitrary behavious. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
