Simple query hangs forever

[tfausak]

I want to handle Postgres notifications with Hasql. I read through #43 and ended up trying out version 0.20.0.1. Unfortunately I didn't get to notifications because I couldn't get a simple query to work. It hangs forever when trying to execute the query. I'm doing something like this:

Right connection <- open (TCPConnectionSettings "localhost" 5432) "postgres" "" Nothing print
batch connection (statement (prepared "select 1" mempty ignore) ())

I put the whole thing in a Gist. I definitely could be doing something wrong. Is this correct? If so, why is it hanging forever?

This happens on my macOS laptop with GHC 8.2.1 and Postgres 10. I also tried Postgres 9.6 and an unprepared statement; both of those hung forever too.

[nikita-volkov]

Thanks for trying out the beta! The early bird use-testing will be very helpful!

I have no doubt it is a Hasql bug, so it shouldn't have anything to do with the GHC version or Postgres. Hasql's beta version is under active development and is very poorly tested so far, so bugs like this should come at no surprise.

I'm currently focused on other tasks with the beta, but I will address this bug soon, and it will be included in the test-suite. Thanks for reporting!

[tfausak]

Thanks for the quick response! Let me know if I can do anything to help.

[nikita-volkov]

That would very much depend on the level of involvement you're looking for. The largest issue right now is optimizing the GC. I'm currently at the level of 65% of efficiency and considering the possible causes and reapproaching some of the problems all over.

In case that's too much I'll definitely need testers, once I solve that, so I'll keep you in mind.

[tfausak]

I know next to nothing about garbage collectors, much less optimizing GHC's. I'm not at all familiar with Hasql's internals, so I'll poke around there and see if I can make any productive changes 😄

[tfausak]

Unrelated to the original issue, I had some trouble building this project on my machine.

[17 of 42] Compiling Hasql.Core.Loops.Receiver ( library/Hasql/Core/Loops/Receiver.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/Hasql/Core/Loops/Receiver.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.2 for x86_64-apple-darwin):
        Simplifier ticks exhausted
  When trying UnfoldingDone assert
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  To see detailed counts use -ddump-simpl-stats
  Total ticks: 9040

I worked around it by passing -fsimpl-tick-factor=1000 to GHC.

[tfausak]

For what it's worth, I have chased the original problem down to this line:

hasql/library/Hasql/Core/Dispatcher.hs

Line 57 in 65fa1ff

atomically (fmap (Left . TransportError) (readTMVar transportErrorVar) <|> takeTMVar resultVar)

Abusing STM a little, I can see that both TMVars are empty when it tries to read from them.

diff --git a/library/Hasql/Core/Dispatcher.hs b/library/Hasql/Core/Dispatcher.hs
index 1268dc8..32e2821 100644
--- a/library/Hasql/Core/Dispatcher.hs
+++ b/library/Hasql/Core/Dispatcher.hs
@@ -54,6 +55,11 @@ performRequest (Dispatcher _ _ _ _ _ serializerMessageQueue _ resultProcessorQue
       writeTQueue resultProcessorQueue (K.ResultProcessor ir (atomically . putTMVar resultVar))
       writeTQueue serializerMessageQueue (H.SerializeMessage builder)
       writeTQueue serializerMessageQueue (H.FlushMessage)
+    atomically $ do
+      x <- tryReadTMVar transportErrorVar
+      Debug.Trace.traceM ("transportErrorVar = " ++ show x)
+      y <- tryReadTMVar transportErrorVar
+      Debug.Trace.traceM ("resultVar = " ++ show y)
     atomically (fmap (Left . TransportError) (readTMVar transportErrorVar) <|> takeTMVar resultVar)
 
 stop :: Dispatcher -> IO ()

transportErrorVar = Nothing
resultVar = Nothing

That's not really a problem, though. It should retry until one of the TMVars is full. My current best guess is that something's gone wrong with the resultProcessorQueue.

[nikita-volkov]

Concerning the tick factor thing, it's a GHC bug. You can report it on it's tracker. In the mean time we'll have to work around it in Hasql to stay compatible with GHC 8.0.

Concerning the freeze issue, thanks for looking at it! Yes, it seems most likely that the result processor never puts the result in the var. I'll take a look.

[tfausak]

Great, thanks!

Seems like the GHC bug has already been reported: https://ghc.haskell.org/trac/ghc/ticket/14338