Re: Large objects and out-of-memory

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Large objects and out-of-memory
Дата
Msg-id X+VFhCg3dFJvsyX2@paquier.xyz
обсуждение исходный текст
Ответ на Re: Large objects and out-of-memory  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: Large objects and out-of-memory  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
On Thu, Dec 24, 2020 at 05:06:34PM +0300, Konstantin Knizhnik wrote:
> Also I noticed small inconsistency in inval.c:
>
>     else if (msg->id == SHAREDINVALSNAPSHOT_ID)
>     {
>         /* We only care about our own database and shared catalogs */
>         if (msg->rm.dbId == InvalidOid)
>             InvalidateCatalogSnapshot();
>         else if (msg->rm.dbId == MyDatabaseId)
>             InvalidateCatalogSnapshot();
>     }
>
> Here we are processing snapshot invalidation message but using structure for
> relation map invalidation.
> It doesn't cause problems because only dbId field is used and it has the
> same offset
> in SharedInvalRelmapMsg and SharedInvalSnapshotMsg structures.
> But it should be fixed.

Good catch.  It is very easy to miss that this is not "rm", but "sn".
I have checked the rest of this area and did not notice similar
errors.  I'll backpatch the attached if there are no objections.  This
may look cosmetic, but this would cause unnecessary conflicts if this
area gets touched and it would be hard to miss.  This comes from
568d413.  There may be a point in having a single call to
InvalidateCatalogSnapshot() as well..
--
Michael

Вложения

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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: BUG #16771: Server process killed by signal 9, after recovery drop tablespace failed
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data