Re: race condition in pg_class

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: race condition in pg_class
Дата
Msg-id ZkHIf7GSvd7Q1-Xj@paquier.xyz
обсуждение исходный текст
Ответ на Re: race condition in pg_class  (Noah Misch <noah@leadboat.com>)
Ответы Re: race condition in pg_class
Список pgsql-hackers
On Sun, May 12, 2024 at 04:29:23PM -0700, Noah Misch wrote:
> I'm attaching patches implementing the LockTuple() design.  It turns out we
> don't just lose inplace updates.  We also overwrite unrelated tuples,
> reproduced at inplace.spec.  Good starting points are README.tuplock and the
> heap_inplace_update_scan() header comment.

About inplace050-tests-inj-v1.patch.

+    /* Check if blocked_pid is in injection_wait(). */
+    proc = BackendPidGetProc(blocked_pid);
+    if (proc == NULL)
+        PG_RETURN_BOOL(false);    /* session gone: definitely unblocked */
+    wait_event =
+        pgstat_get_wait_event(UINT32_ACCESS_ONCE(proc->wait_event_info));
+    if (wait_event && strncmp("INJECTION_POINT(",
+                              wait_event,
+                              strlen("INJECTION_POINT(")) == 0)
+        PG_RETURN_BOOL(true);

Hmm.  I am not sure that this is the right interface for the job
because this is not only related to injection points but to the
monitoring of a one or more wait events when running a permutation
step.  Perhaps this is something that should be linked to the spec
files with some property area listing the wait events we're expected
to wait on instead when running a step that we know will wait?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Converting README documentation to Markdown
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Parallel CREATE INDEX for GIN indexes