On Tue, Jun 02, 2026 at 05:11:52PM -0500, Nathan Bossart wrote: > * I'm a little worried about race conditions involving a client trying to > use a statement while a deallocation message is in flight, but I haven't > identified anything concrete so far. This is something I'd like to > investigate some more, though.
Hm. So there's actually a pretty obvious problem here. Say a user executes something like PQsendQuery(conn, "DISCARD ALL") and then tries to execute an lo_* function (modified to use prepared statements) prior to consuming the result. In that case, the callback won't be called in time and the LO function will fail. My first instinct is that this is a showstopper for $subject, but perhaps it is a rare enough scenario that we could live with documenting it. My suspicion is that it's uncommon for folks to asynchronously deallocate all prepared statements, and I don't know why you'd use PQsendClosePrepared() on statements named libpq_internal_*. Nevertheless, this seems like a rather large hole. I think this calls into question whether moving the libpq interface to prepared statements makes sense. If we can't do that, I think we're pretty much forced to keep the fast-path around forever or to accept a larger performance hit. In any case, I find it a little strange that there's not a great way to use prepared statements internally in libpq, which is why I'm chasing this a little more than perhaps I should. -- nathan
