Since SBCL 1.0.26 or so, there's been a sanity check in interrupt handling that ensures that all signals in a set are either blocked or unblocked. This check is dumping SBCL into LDB, and here's why:
Postgresql's libpq will block sigpipe for its own reasons. When another interrupt is signaled during a query (PQexec or PQsendQuery), SBCL has to decide what to do about the interrupt, whether to handle it or not. What winds up happening though is that the sanity check runs and sees that signal 13 is blocked, while the rest of the set of "deferrable" signals are not. It does not expect this, freaks out, and you get dumped into LDB.
To get around it, calls to PQexec need to get wrapped in sb-thread::block-deferrable-signals and sb-unix::unblock-deferrable-signals for now. It's a bummer, as potentially useful signals like sigint and sigalrm will get blocked.
I'm also going to try a patched sbcl that allows sbcl to tell the sanity check to ignore checking certain blocked signals, which isn't the best solution, but it's the quick and dirty solution I thought up. Hopefully future SBCLs will play nice with shared object library functions, but only time will tell.
Regards, Andrew Golding