From: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
---|---|
To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
Cc: | Stepan Neretin <slpmcf(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Accessing an invalid pointer in BufferManagerRelation structure |
Date: | 2025-10-20 19:03:35 |
Message-ID: | CAJDiXgiQXRWZ+n=fHaLqzLkGt6y9DY4_HPELPwaq3AVcFGYKtA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Sun, Oct 19, 2025 at 6:32 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> I edited your comments a bit. What do you think of this version?
>
Thanks for looking into this! All added changes LGTM.
> I don't think this is backpatchable material, mainly because you said
> you don't see any situations in which relcache invalidations would
> occur in the middle of this. Can you can cause a problem to occur by
> adding an untimely invalidation somewhere without this patch, which is
> fixed by this patch?
Yep, by now (if I did not miss anything) described problem cannot occur even
with debug_discard_caches parameter on. But one of our clients had faced
this problem, because we have some differences in source code. In the first
letter I described scenario, when the occurrence of a problem becomes possible :
***
if (just for example) we add acquiring of new lock into ExtendBufferedRelLocal
or ExtendBufferedRelShared, relation cache will be invalidated (inside
AcceptInvalidationMessages).
***
>
> BTW how does this interact with SMgrRelation pinning?
Hm, maybe I don't fully understand the question. Smgr pinning is one of the side
effects of BMR_GET_SMGR (in case we use this macro with
invalidated/uninitialized
rd_smgr entry).
Without patch pincount cannot save us from undesirable invalidation,
because it guards
from smgr_destroy, not from smgr_release.
--
Best regards,
Daniil Davydov
From | Date | Subject | |
---|---|---|---|
Next Message | Mihail Nikalayeu | 2025-10-20 19:27:00 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
Previous Message | Dimitrios Apostolou | 2025-10-20 18:40:27 | [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward |