| 00:00.22 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 01:12.53 | *** join/#storm milosn (~milosn@5ac6762b.bb.sky.com) |
| 02:21.29 | *** join/#storm bigjools (~quassel@ppp59-167-159-180.static.internode.on.net) |
| 02:21.29 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 05:01.08 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 08:27.02 | *** join/#storm lifeless (~robertc@122.58.129.196) |
| 08:29.41 | *** join/#storm esteve (~quassel@31.4.239.147) |
| 09:05.52 | *** join/#storm esteve_ (~quassel@cli-5b7eed72.bcn.adamo.es) |
| 09:18.37 | *** join/#storm lifeless (~robertc@122.58.129.196) |
| 09:32.14 | *** join/#storm esteve (~quassel@cli-5b7eed72.bcn.adamo.es) |
| 12:25.35 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 13:56.31 | *** join/#storm niemeyer (~niemeyer@189-10-219-18.pltce701.dsl.brasiltelecom.net.br) |
| 13:56.31 | *** mode/#storm [+o niemeyer] by ChanServ |
| 15:13.39 | therve | anybody using Postgres 9.1 and storm? |
| 15:13.56 | therve | jkakar, you're using hype technology aren't you? |
| 15:21.37 | magmatt | therve: 8.4, but hope to use 9.1 soon |
| 15:22.32 | therve | magmatt, ok. If I talked to you about SERIALIZABLE and REPEATABLE READ, do you have an idea? |
| 15:24.04 | magmatt | therve: the isolation level... yeah, I turned ours to read-committed |
| 15:24.13 | therve | ah ok, so that's fine |
| 15:24.33 | therve | magmatt, there is a change in semantic in 9 for SERIALIZABLE |
| 15:24.41 | therve | but if you already switched, that's ok |
| 15:43.37 | _mup_ | storm/postgres-repeatable-read r442 committed by thomas@canonical.com |
| 15:43.37 | _mup_ | Dynamically set the isolation, and juggle with postgres and psycopg versions |
| 15:51.57 | jkakar | therve: Heya... |
| 15:52.10 | jkakar | therve: I'm using the new hype technology, yes. Go+MongoDB ftw! |
| 15:52.16 | therve | heh |
| 15:52.30 | jkakar | therve: But, uh, I noticed your report about transactions and PostgreSQL 9.1... I don't really understand the issue(s). |
| 15:52.31 | therve | you're web scaling |
| 15:52.42 | jkakar | No, I'm scaling the web. |
| 15:53.06 | therve | http://wiki.postgresql.org/wiki/Serializable has some explanations |
| 15:53.12 | jkakar | reads |
| 15:53.24 | therve | the key is : "Those who want to continue to use snapshot isolation without the additional protections of SSI (and the associated costs of enforcing those protections), can use the REPEATABLE READ transaction isolation level. This level retains its legacy behavior, which is identical to the old SERIALIZABLE implementation and fully consistent with the standard's requirements for the REPEATABLE READ transaction isolation level" |
| 15:53.40 | therve | legacy means < 9 here |
| 15:55.29 | jkakar | therve: Ah, okay, got it. |
| 15:56.00 | jkakar | therve: So I guess we'll change our default isolation level from SERIALIZABLE to REPEATABLE READ...? |
| 15:56.19 | jkakar | therve: Or do we want to continue to connect with SERIALIZABLE and let users decide whether they want REPEATABLE READ? |
| 15:56.35 | therve | jkakar, I'm leaning towards changing |
| 15:56.46 | jkakar | therve: That's kind of my gut feel too. |
| 15:56.46 | therve | that's what the branch I just pushed does |
| 15:56.50 | jkakar | Okay. |
| 15:57.27 | *** join/#storm m4v (~znc@unaffiliated/m4v) |
| 15:57.49 | jkakar | therve: Actually, thinking more, we need to keep SERIALIZABLE to ensure that connecting to older versions of Storm still works as expected, right? |
| 15:58.34 | jkakar | therve: Oh, I see, you already did that... |
| 15:58.40 | jkakar | I guess reading code is pretty useful. :) |
| 15:58.44 | therve | yeah :) |
| 15:59.01 | therve | as we already had version detection, it was fairly easy |
| 16:02.38 | jkakar | therve: +1, thanks for fixing it! |
| 19:57.43 | *** join/#storm mgedmin (~mg@Maemo/community/contributor/mgedmin) |
| 19:57.54 | mgedmin | anybody ever used Storm in conjunction with ZEO? |
| 19:59.44 | mgedmin | I'm seeing happy fun deadlocks |
| 19:59.59 | mgedmin | ZEO ClientStorage enforces a condition: only one thread may commit at any time |
| 20:00.26 | mgedmin | now I'm looking at a hung application where multiple threads are waiting inside ClientStorage.tpc_begin, waiting for the active transaction to finish |
| 20:00.39 | mgedmin | and one thread is blocked inside storm/database.py, in _check_disconnect |
| 20:01.00 | mgedmin | my guess is that two threads were committing a PostgreSQL transaction |
| 20:01.05 | mgedmin | which conflicted |
| 20:01.42 | mgedmin | and one of them is now trying to commit to ZEO before it finishes comitting to postgresql |
| 20:01.54 | mgedmin | while the other is holding a ZEO lock and waiting for postgresql |
| 20:02.05 | mgedmin | I'm not entirely sure my understanding is correct |
| 20:02.24 | mgedmin | all I have to go on is a list of stack frames of all the threads |
| 20:40.52 | jkakar | mgedmin: Ew, that sounds bad. I've never used ZEO. :( |
| 20:41.17 | jkakar | mgedmin: I guess an issue is that they're probably both using the same underlying transaction manager...? Maybe that can be teased apart. |
| 21:12.19 | *** join/#storm kr4d10 (~kr4d10@2001:49f0:a01d::203) |
| 23:05.52 | *** join/#storm jamesh (~james@canonical/launchpad/jamesh) |