Hi Shihao,
While discussing with LLM, I found that the current code might stuck in future,
when the callbacks in ProcessProcSignalBarrier() returns false.
According to the code comment, it can return false if it's not an appropriate
time thus we must try once again. At that time, the latch seems not to be set.
I came up with the below case for read:
1. callbacks in ProcessProcSignalBarrier() returns false.
2. it returns without seting the latch again.
3. secure_read() tries to read from the socket, but nothing found again
(errno == EAGAIN)
4. The backend reaches WaitEventSetWait() again. The caller side of the barrier
also keeps waiting.
I could reproduce with your patch set and below change. The reproducer could
stuck again on my env.
```
bool
ProcessBarrierSmgrRelease(void)
{
+ static bool defer_once = true;
+
+ /*
+ * If this called from ProcessClientBarrierInterrupt() for the first
time,
+ * do no-op and returns false. This simulates the case we have to try
once
+ * again.
+ */
+ if (ExitOnAnyError && defer_once)
+ {
+ defer_once = false;
+ return false;
+ }
+
```
Actually, I'm quite unclear how we should fix. Should we just note the risk
somewhere because it does not happen yet? Another primitive idea is to set the
latch again in ProcessClientBarrierInterrupt() if ProcSignalBarrierPending is
still
true, but it may waste the CPU time, wait in the secure_read() may finish soon
and check the socket again may times.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
