fix: a batch could be dropped without processing

[imor]

If the first call to wait_event returned with an EINTR error, the continue statement jumped the control to the while (running_handles > 0) condition. Since running_handles was initialized to 0, it exited the loop and committed the open transaction, dropping the entire batch without processing it.

Since it is timing dependent and hard to write a deterministic test for, a test reproducing with sleeping is committed here: e73dd12

[steve-chavez]

LGTM. Disregard previous comment, just read the test.

[imor]

If the first call to wait_event returned with an EINTR error

Can you elaborate how do you trigger EINTR? I was only able to trigger that with gdb:

pg_net/src/worker.c

Lines 354 to 355 in b92fa5a

	if (save_errno == EINTR) { // can happen when the wait is interrupted, for example when
	// running under GDB. Just continue in this case.

If no real world condition triggers this, then it wouldn't be a fix strictly speaking.

There is a real world condition that triggers this, it's just very rare: when the worker is waiting in epoll_wait/kevent and a signal is delivered to the process it returns EINTR. Which means if someone was trying to reload the conf by sending a sighup, this condition would occur. That comment about GDB in the code is only partially correct, I'll update it. Even in the GDB case we'd want the code to not drop the batch.

[AndrewJackson2020]

Can we fix the spelling in the PR title? withour -> without

[imor]

Can we fix the spelling in the PR title? withour -> without

Done