Fix bug related with queries to dead backends

[CherkashinSergey]

Исправлен баг: во время слоных запросов pg_query_state иногда пытался опрашивать процессы, которые уже завершили свою работу.

[codecov-io]

Codecov Report

Merging #10 into master will decrease coverage by 1.09%.
The diff coverage is 9.09%.

@@            Coverage Diff            @@
##           master      #10     +/-   ##
=========================================
- Coverage   76.78%   75.69%   -1.1%     
=========================================
  Files           5        5             
  Lines         461      469      +8     
=========================================
+ Hits          354      355      +1     
- Misses        107      114      +7

Impacted Files	Coverage Δ
pg_query_state.c	71.94% <9.09%> (-1.27%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7d5f98...91e3196. Read the comment docs.

[ildus]

вот здесь тоже надо через continue, бекенд может помереть и в этом месте

[maksm90]

Нет, Assert тут правильнее - мы предполагаем, что proc никогда не будет нулевым. А вот условие !proc->pid лишнее.

[ildus]

А с чего ты взял что он не может быть нулевым?

[za-arthur]

У вас тут условие есть в GetRemoteBackendWorkers()

if (!proc || !proc->pid)
   continue;

Поэтому видимо не может быть нулевым.

[ildus]

Тут в смысле proc нулевым не будет в любом случае, но процесс мог умереть (или завершиться) и проверка на pid все равно нужна. По хорошему вообще SHARED лок надо ставить на procArray

[maksm90]

@ildus зачем смёржил свой вариант!?

[ildus]

@maksm90 ответь на вопрос, всегда успеем отменить если нужно.

[maksm90]

На какой? Выше вроде на всё ответил. Список pworkers как входной аргумент GetRemoteBackendQueryStates должен состоять из ненулевых proc - это предусловие. Обеспечиваем это условие на уровне выше в GetRemoteBackendWorkers - это будет постусловием для этой функции. Это обеспечивается вставкой continue в цикл:

for (i = 0; i < msg->number; i++)
{
	pid_t 	 pid = msg->pids[i];
	PGPROC	*proc = BackendPidGetProc(pid);

	result = lcons(proc, result);
}

[ildus]

Это указатели на структуры в shared memory, откуда предположение что pid у них будет валидным всегда?

[maksm90]

Тут соглашусь, гонки с аллокатором ProcArray могут быть. Тогда имеет смысл работать с pid'ами, а не со структурами PGPROC. Валидность pid'а мы сможем определить, отправляя сигнал (вызов SendProcSignal) или выполняя резолв на PGPROC. Пока мы остановимся на предположении, что гонки допустимы, но маловероятны. Для их полного разрешения надо переписывать всю логику взаимодействия, уменьшая кол-во RPC между процессами. Но это уже будет задача для следующей стадии.