I tried digging into this, but I can't seem to get past datafusion/deltalake, so maybe it's coming from within one of those crates? Or it could be something wrong in our implementation.
If you create a new table and insert into it and then try to execute a query with a UDF, the UDF crashes because pgrx won't operate on a new thread. The UDF executes on a different thread from the main one. If you call paradedb.init() and try again, it works... This also happens after a table has been newly truncated and inserted into. It isn't a problem after inserting on a non-empty table. For now, there's a stopgap solution to make sure we avoid the crash, but it doesn't get to the root of the threading issue.
@neilyio also reported some weird behavior with executing SQL directly from Rust when a new table is created and then inserted into in the same semicolon-separated query. The new data just doesn't get inserted!
I tried digging into this, but I can't seem to get past datafusion/deltalake, so maybe it's coming from within one of those crates? Or it could be something wrong in our implementation.
If you create a new table and insert into it and then try to execute a query with a UDF, the UDF crashes because pgrx won't operate on a new thread. The UDF executes on a different thread from the main one. If you call
paradedb.init()
and try again, it works... This also happens after a table has been newly truncated and inserted into. It isn't a problem after inserting on a non-empty table. For now, there's a stopgap solution to make sure we avoid the crash, but it doesn't get to the root of the threading issue.@neilyio also reported some weird behavior with executing SQL directly from Rust when a new table is created and then inserted into in the same semicolon-separated query. The new data just doesn't get inserted!