Re: race condition in pg_class
| От | Michail Nikolaev |
|---|---|
| Тема | Re: race condition in pg_class |
| Дата | |
| Msg-id | CANtu0ogYLrufbSWOLDjfcDNCU=R6i2SJCEG_Uejtezx_+2vHng@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: race condition in pg_class (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: race condition in pg_class
|
| Список | pgsql-hackers |
Hello!
> looks like a valid report of an important bug, but I'm not following the
> potential relationship to $SUBJECT.
I was guided by the following logic:
* A pg_class race condition can cause table indexes to look stale.
* REINDEX updates indexes
* errors can be explained by different backends using different arbiter indexes
* A pg_class race condition can cause table indexes to look stale.
* REINDEX updates indexes
* errors can be explained by different backends using different arbiter indexes
> On your other thread, it would be useful to see stack traces from the high-CPU
> processes once the live lock has ended all query completion.
I'll do.
Best regards,
Mikhail.
В списке pgsql-hackers по дате отправления: