Comment 14 for bug 1273636

More debugging with Stuart, here are the findings:

<stub> matsubara: Gah. You did this deliberately. The race is hard to spot, because the generated database name was test-catalog, but the one your charm is testcatalog
<stub> matsubara: Don't worry about fsync, I've identified the race.
<matsubara> stub, well, the charm did allow us to change the db name, so I'm working with the defined interface
<stub> https://pastebin.canonical.com/104024/
<stub> matsubara: yes. What you are doing is supposed to work, and even works in my test suite. But I can't guarantee the order of hooks in my test suite.
<stub> So the server -joined hook runs first, and grants access to the client to the generated database. The server doesn't yet know that the client wants a different database name.
<stub> Then the client sets the database name in its joined hook
<stub> And then runs its -changed hook, which attempts to connect to the database it wants to use.
<stub> And this fails because the server is still in the process of creating the requested database.
<stub> And this would be obvious if the database names were not so similar ;)
<matsubara> stub, so, should I change the test-catalog naming convention or is this something that you can change in the PG charm to deal with? I guess others might run in the same problem if they want to set the db name to something else.
<stub> matsubara: It is a bug in the PostgreSQL charm.
<stub> I'm trying to think of the best way to fix the race
<matsubara> stub, nasty bug, glad I exposed it before others start to use it more heavily. I'll update the bug report with the IRC log of the finding and let you work. Thanks a lot for your help!