Jean Boussier
Jean Boussier
I don't know enough about postgres to know whether this is correct.
> Have you seen this? Do you have any ideas? No, but this is indeed extremely weird. I don't see how `IO.pipe` could possibly return anything other than a pair...
> * we're not using yjit That's helpful, that remove a very large suspect. I'd suggest running a patched version of puma that adds a few nil checks to try...
> I'm not clear on how a user can overwrite that behaviour. https://guides.rubyonrails.org/configuring.html#config-yjit If you can, it would be very valuable to turn off YJIT and see if the problem...
> If this is in fact a yjit issue does that change the debugging approach Yes. It reduce the search area a lot. > I wonder if yjit does something...
No worries. Also I posted this issue in the YJIT team channel, and someone pointed to me a very similar bug triggered in `sorbet-runtime` (also an ivar turning to `nil`...
Yes, it is expected behavior. Any `--yjit-*` option immediately enable YJIT like `--yjit` would. So the difference with not providing anything is that it doesn't wait for the Rails initializer...
So I think this is a valuable feature, however some quick testing show this syntax is also valid in MySQL and SQLite3, so it shouldn't be exclusive to the Postgres...
> I'd prefer that we look to achieve the `where([:a, :b] => [[1, 2], [3, 4]])` syntax directly, I think both are valuable.
> would an application ever need to be able to do Such a simple example no. But I believe it's important for Rails to provide decent escape hatches for when...