Hi, On 2020-07-03 17:00:49 -0700, Andres Freund wrote: > I haven't yet fully analyzed the problem, but after updating to > cdd3bb54332f82295ed90cd0c09c78cd0c0ee822 io_uring using postgres does > not work reliably anymore. > > The symptom is that io_uring_enter(IORING_ENTER_GETEVENTS) isn't > interrupted by signals anymore. The signal handler executes, but > afterwards the syscall is restarted. Previously io_uring_enter reliably > returned EINTR in that case. > > Currently postgres relies on signals interrupting io_uring_enter(). We > probably can find a way to not do so, but it'd not be entirely trivial. > > I suspect the issue is > > commit ce593a6c480a22acba08795be313c0c6d49dd35d (tag: io_uring-5.8-2020-07-01, linux-block/io_uring-5.8) > Author: Jens Axboe <axboe@xxxxxxxxx> > Date: 2020-06-30 12:39:05 -0600 > > io_uring: use signal based task_work running > > as that appears to have changed the error returned by > io_uring_enter(GETEVENTS) after having been interrupted by a signal from > EINTR to ERESTARTSYS. > > > I'll check to make sure that the issue doesn't exist before the above > commit. Indeed, on cd77006e01b3198c75fb7819b3d0ff89709539bb the PG issue doesn't exist, which pretty much confirms that the above commit is the issue. What was the reason for changing EINTR to ERESTARTSYS in the above commit? I assume trying to avoid returning spurious EINTRs to userland? Greetings, Andres Freund
