Re: Large objects and out-of-memory

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Large objects and out-of-memory
Date: 2020-12-25 01:51:00
Message-ID: X+VFhCg3dFJvsyX2@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
inval-inconsistent.patch text/x-diff 621 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2020-12-25 09:05:04 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Kyotaro Horiguchi 2020-12-25 00:20:25 Re: BUG #16771: Server process killed by signal 9, after recovery drop tablespace failed