You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
initial commit of rejiggering how pgrx tracks the "ACTIVE_THREAD". This
is to address issue pgcentralfoundation#2228.
Functions annotated with `#[pg_guard(unsafe_entry_thread)]` do some
trickery to reset pgrx' understanding of the "ACTIVE_THREAD" so that
whatever thread happens to be calling that function then becomes our
understanding of the "ACTIVE_THREAD", thereby allowing pgrx to do
Postgres FFI on a thread that isn't the main thread.
The situation behind pgcentralfoundation#2228 is that pg_duckdb, an extension written in
C++, uses threads (presumably "safely") within Postgres and if one of
those threads does something like SPI, which then causes
planner/executor hooks to be called, and one of those hooks is
implemented with pgrx, this new `unsafe_entry_thread` tag will let that
callback run. It's basically making an assumption that the caller is
properly managing the thread it's on.
There's very little code changes here -- the bulk of the PR is a new
example crate/extension with its own little c-shim so that I could
manually test Postgres itself kicking off a thread that does SPI that
ends up calling into a planner hook setup by the rust/pgrx extension.
I have a need to push this through for $DayJob, so I'm probably going to
do that later this week.
---------
Co-authored-by: Eric B. Ridge <[email protected]>
0 commit comments