From: | Stepan Neretin <slpmcf(at)gmail(dot)com> |
---|---|
To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Accessing an invalid pointer in BufferManagerRelation structure |
Date: | 2025-05-10 17:36:27 |
Message-ID: | CA+Yyo5RZps-LLDd1Jiub5qVg-3hz+r0gi3F_fk+6=nmtGaOgHA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 14, 2025 at 1:10 PM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
> Hi,
>
> On Wed, Mar 26, 2025 at 2:14 PM Stepan Neretin <slpmcf(at)gmail(dot)com> wrote:
> >
> > The first thing we both noticed is that the macro calls a function that
> won't be available without an additional header. This seems a bit
> inconvenient.
>
> Well, I rebased the patch onto the latest `master`
> (b51f86e49a7f119004c0ce5d0be89cdf98309141) and noticed that we don't
> need to include `rel.h` in `localbuf.c` directly anymore, because
> `#include lmgr.h` was added in memutils.h
> I guess it solves this issue. Please, see v3 patch.
>
> > I also have a question: is the logic correct that if the relation is
> valid, we should fetch it rather than the other way around? Additionally,
> is checking only the `rd_isvalid` flag sufficient, or should we also
> consider the flag below?
> >
> > ```
> > bool rd_isvalid; /* relcache entry is valid */
> >
>
> I don't think that we should check any Relation's flags here. We are
> checking `RelationIsValid((bmr).rel) ?` to decide whether
> BufferManagerRelation was created via BMR_REL or BMR_SMGR.
> If the `rel` field is not NULL, we can definitely say that BMR_REL was
> used, so we should call RelationGetSmgr in order to access smgr.
>
> --
> Best regards,
> Daniil Davydov
>
Hi, now looks good for me.
--
Best regards,
Stepan Neretin
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-05-10 17:59:27 | Re: Restrict publishing of partitioned table with a foreign table as partition |
Previous Message | Noah Misch | 2025-05-10 15:14:23 | Re: Inval reliability, especially for inplace updates |