Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→ 502,152 events total
2021-03-15 14:40:18 <yahb> dminuoso: Hello World, Frank
2021-03-15 14:40:45 <dminuoso> % let f = putStr " World" >> putStrLn ", Frank" in (putStr "Hello" >> f)
2021-03-15 14:40:45 <yahb> dminuoso: Hello World, Frank
2021-03-15 14:41:18 <dminuoso> As programmers this associativity might be intuitive and natural. Since IO is a monad, we can argue that this holds true precisely for the monad laws.
2021-03-15 14:41:43 marinelli joins (~marinelli@gateway/tor-sasl/marinelli)
2021-03-15 14:46:00 × ddellacosta quits (ddellacost@gateway/vpn/mullvad/ddellacosta) (Remote host closed the connection)
2021-03-15 14:46:17 <__minoru__shirae> why am I thinking about this: there was a question about applying a regular function to a monad
2021-03-15 14:46:33 <__minoru__shirae> and the first thing that came to my mind was using bind with return
2021-03-15 14:46:56 <__minoru__shirae> I forgot about much simpler solution that uses fmap
2021-03-15 14:47:24 <__minoru__shirae> So, now I think, why did I miss it? Maybe I'm missing some intuition here?
2021-03-15 14:50:39 rj_ joins (~x@gateway/tor-sasl/rj)
2021-03-15 14:50:40 <__minoru__shirae> maybe the intuition is as simple as "a monad is a functor"
2021-03-15 14:50:51 <__minoru__shirae> nothing fancy
2021-03-15 14:51:09 <dminuoso> Well, all monads are functors, yes.
2021-03-15 14:52:07 <__minoru__shirae> ok, I think it takes time to get used to that idea at a subconscious level
2021-03-15 14:52:41 × jamm_ quits (~jamm@unaffiliated/jamm) (Remote host closed the connection)
2021-03-15 14:52:58 <dminuoso> I think the main problem with the term "monad" is that it makes you want to understand "what is a monad" - and the question is about as useful as "what is a monoid"
2021-03-15 14:53:09 × royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-03-15 14:53:09 <dminuoso> or "what is a semigroup"
2021-03-15 14:53:29 royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-03-15 14:53:32 × polyphem quits (~p0lyph3m@2a02:810d:640:776c:76d7:55f6:f85b:c889) (Ping timeout: 260 seconds)
2021-03-15 14:53:41 <dminuoso> And while people say "the IO monad", you rarely hear people talking about "the Integer semigroup"
2021-03-15 14:54:24 <Uniaika> (I hope not!!)
2021-03-15 14:54:35 <merijn> dminuoso: https://blog.jle.im/entry/io-monad-considered-harmful.html :p
2021-03-15 14:54:44 <merijn> There, saved you some typing and explanation ;)
2021-03-15 14:55:13 <dminuoso> merijn: Yeah, that's not quite what Im getting at
2021-03-15 14:55:22 peanut_ joins (~peanut@2a02:8388:a101:2600:6b6d:4c3f:e9f8:2601)
2021-03-15 14:56:13 <dminuoso> It's just that, being a semigroup has no meaning other than satisfying some laws. It doesn't tell you at all what the operation means, or any other properties.
2021-03-15 14:56:18 <dminuoso> And monad is just the same
2021-03-15 14:56:25 jessty joins (~jessty___@180.254.160.158)
2021-03-15 14:57:58 × royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 245 seconds)
2021-03-15 14:58:09 <codygman`> I've been hitting a wall debugging a "libpq: failed (another command is already in progress" error using Data.Pool with persistent. I was wondering if anyone here might be able to help. It seems like Data.Pool happily puts back connections that still have queries running on them. Way more detail here: https://github.com/yesodweb/persistent/issues/1199
2021-03-15 14:58:31 × zebrag quits (~inkbottle@aaubervilliers-654-1-101-29.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-03-15 14:58:52 zebrag joins (~inkbottle@aaubervilliers-654-1-101-29.w86-212.abo.wanadoo.fr)
2021-03-15 14:59:08 <dminuoso> codygman`: Did you see https://github.com/lpsmith/postgresql-simple/issues/177?
2021-03-15 14:59:21 × Ranhir quits (~Ranhir@157.97.53.139) (Read error: Connection reset by peer)
2021-03-15 15:00:18 × Kaiepi quits (~Kaiepi@47.54.252.148) (Remote host closed the connection)
2021-03-15 15:00:36 <merijn> codygman`: Are you using any of the conduit query functions from persistent?
2021-03-15 15:00:58 <merijn> codygman`: like selectSource
2021-03-15 15:01:07 × raehik1 quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Quit: WeeChat 3.0.1)
2021-03-15 15:01:18 <codygman`> We were in prod, but I reproduced without conduit here: https://github.com/codygman/persistent-postgresql-query-in-progress-repro/blob/master/src/Main.hs
2021-03-15 15:01:18 <codygman`>
2021-03-15 15:01:24 jamm_ joins (~jamm@unaffiliated/jamm)
2021-03-15 15:02:14 <dminuoso> Oh nvm me
2021-03-15 15:02:36 × malumore quits (~malumore@151.62.122.60) (Remote host closed the connection)
2021-03-15 15:02:55 <dminuoso> codygman`: Just a random thought, but you are not using COPY are you?
2021-03-15 15:03:18 heatsink joins (~heatsink@2600:1700:bef1:5e10:7c0e:3b57:dfb:2cb4)
2021-03-15 15:03:44 <codygman`> We are using LISTEN in prod via oddjobs, but in that minimal repro it's just a simple rawSql query.
2021-03-15 15:07:30 <codygman`> If interested and one has the time, it's easy to run yourself with stack and the copy-pastable docker postgres here: https://github.com/codygman/persistent-postgresql-query-in-progress-repro/blob/958e66963c0ad9761149f7ef97fd5ec0d7322f73/src/Main.hs#L21
2021-03-15 15:07:35 × heatsink quits (~heatsink@2600:1700:bef1:5e10:7c0e:3b57:dfb:2cb4) (Ping timeout: 240 seconds)
2021-03-15 15:08:03 <merijn> codygman`: Hold on
2021-03-15 15:08:34 <merijn> codygman`: Are you *sure* the exception happens during the rawSql
2021-03-15 15:08:51 jessty_ joins (~jessty___@180.254.160.158)
2021-03-15 15:08:57 <merijn> codygman`: It looks to me that that exception is just from your concurrent inserts
2021-03-15 15:10:24 Lycurgus joins (~niemand@98.4.115.230)
2021-03-15 15:10:50 tsaka__ joins (~torstein@ppp-2-87-239-251.home.otenet.gr)
2021-03-15 15:10:53 × jessty quits (~jessty___@180.254.160.158) (Ping timeout: 245 seconds)
2021-03-15 15:11:03 × todda7 quits (~torstein@2a02:587:1b10:ea00:db5:2d40:d00d:cce4) (Ping timeout: 272 seconds)
2021-03-15 15:11:31 jakalx joins (~jakalx@base.jakalx.net)
2021-03-15 15:11:59 <codygman`> I know the error is coming from `result`: https://github.com/codygman/persistent-postgresql-query-in-progress-repro/blob/958e66963c0ad9761149f7ef97fd5ec0d7322f73/src/Main.hs#L31. Wouldn't I never get to result if an async exception in inserts happened here: https://github.com/codygman/persistent-postgresql-query-in-progress-repro/blob/958e66963c0ad9761149f7ef97fd5ec0d7322f73/src/Main.hs#L27
2021-03-15 15:12:05 <merijn> Anyway
2021-03-15 15:12:28 <merijn> My recommendation would be to not use persistent if you care about your transactions/cleanup/etc. actually being predictable
2021-03-15 15:12:57 Wuzzy joins (~Wuzzy@p57a2ecf2.dip0.t-ipconnect.de)
2021-03-15 15:13:00 <merijn> The entire API is in an entirely incoherent state and IMO cannot be used safely without spending several hours staring at the persistent internals
2021-03-15 15:13:17 × jessty_ quits (~jessty___@180.254.160.158) (Ping timeout: 265 seconds)
2021-03-15 15:13:47 dyeplexer joins (~lol@unaffiliated/terpin)
2021-03-15 15:14:10 <merijn> actually
2021-03-15 15:14:10 <codygman`> I actually spent the time to fork persistent and use unliftio everywhere. And to use the fork of Data.Pool that uses unliftio. That still didn't help :)
2021-03-15 15:14:10 × ambiso992 quits (~ambiso@209.182.239.205) (Quit: The Lounge - https://thelounge.chat)
2021-03-15 15:14:13 <merijn> I see the issue
2021-03-15 15:14:25 <merijn> And it's related to my existing issue on persistent
2021-03-15 15:14:27 aggin joins (~ecm@103.88.87.37)
2021-03-15 15:14:32 <merijn> codygman`: The problem isn't the pool
2021-03-15 15:14:43 <merijn> codygman`: The problem is that persistent's Statement cache is garbage
2021-03-15 15:14:44 ambiso992 joins (~ambiso@209.182.239.205)
2021-03-15 15:15:23 <codygman`> I saw that conversation and I was exploring that, but wasn't sure how it would affect this in particular.
2021-03-15 15:15:28 <merijn> codygman`: https://hackage.haskell.org/package/persistent-2.11.0.2/docs/src/Database.Persist.Sql.Raw.html#rawExecute
2021-03-15 15:16:03 <merijn> codygman`: Note how: 1) rawExecute is just rawExecuteCount and 2) "stmtReset" is not called via a bracket
2021-03-15 15:16:41 <merijn> codygman`: That means that if you async interrupt the statement, it's not reset, but the connection is returned to the pool
2021-03-15 15:17:15 <merijn> codygman`: I don't know postgres, but I suspect the problem is issuing a new statement while one is "still running"
2021-03-15 15:17:25 <codygman`> It looks like for persistent the postgres stmtReset is just `return ()` lol
2021-03-15 15:17:29 <codygman`> for postgres*
2021-03-15 15:17:57 <merijn> ah, not sure about that
2021-03-15 15:17:59 <codygman`> that is indeed the issue... I tried a workaround where I call PQ.cancel
2021-03-15 15:18:02 <merijn> but that seems weird
2021-03-15 15:18:21 <codygman`> Actually the full solution is: PQ.cancel, PQ.consumeInput, PQ.disconnect
2021-03-15 15:18:23 <merijn> I can't imagine postgres doesn't require resetting/freeing an "in progress" statement
2021-03-15 15:19:06 <codygman`> Okay, I think I'll try out adding that logic into reset
2021-03-15 15:19:06 <codygman`>
2021-03-15 15:19:13 × jrqc quits (~rofl@96.78.87.197) (Ping timeout: 245 seconds)
2021-03-15 15:20:02 polyphem joins (~p0lyph3m@2a02:810d:640:776c:76d7:55f6:f85b:c889)
2021-03-15 15:20:37 <merijn> codygman`: I stand by my earlier recommendation, though :)
2021-03-15 15:22:25 <codygman`> Yeah, but my team is pretty heavily invested in Persistent by now.
2021-03-15 15:22:26 <codygman`>
2021-03-15 15:22:27 jrqc joins (~rofl@96.78.87.197)
2021-03-15 15:22:36 × acarrico quits (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) (Ping timeout: 246 seconds)
2021-03-15 15:22:43 <merijn> codygman`: I know all about sunk cost fallacy :p
2021-03-15 15:22:48 <codygman`> :D
2021-03-15 15:23:06 <merijn> But at least my excuse is that no one is paying me for future maintenance on my code so since it's working now it can just rot
2021-03-15 15:23:33 <merijn> That doesn't apply if you have to maintain it long term :p

All times are in UTC.