On Wed, Apr 30, 2025 at 4:29 PM Daniel Gustafsson
wrote:
> This is indeed exposing a pre-existing issue, which was reported in [0] and a
> patch fixing it has been submitted. I have been testing and reworking the
> patch slightly but due to $life and $work events have yet to have time to push
> i
> On 30 Apr 2025, at 22:17, Robert Haas wrote:
> I kind of doubt whether that's the only problem here, but it's *a* problem.
This is indeed exposing a pre-existing issue, which was reported in [0] and a
patch fixing it has been submitted. I have been testing and reworking the
patch slightly but
On Sat, Apr 26, 2025 at 5:07 PM Tomas Vondra wrote:
> > Just for the record, it sounds quite unsafe to me too. I could
> > credit it being all right to examine the process' MemoryContext data
> > structures, but calling dsa_create() from CFI seems really insane.
> > Way too many moving parts ther
On 4/23/25 20:14, Tom Lane wrote:
> Robert Haas writes:
>> My primary concern about the patch is that
>> ProcessGetMemoryContextInterrupt() can be called from any
>> CHECK_FOR_INTERRUPTS() and calls lots of DSA functions, including
>> dsa_create() and, via PublishMemoryContext(), dsa_allocate0().
Robert Haas writes:
> My primary concern about the patch is that
> ProcessGetMemoryContextInterrupt() can be called from any
> CHECK_FOR_INTERRUPTS() and calls lots of DSA functions, including
> dsa_create() and, via PublishMemoryContext(), dsa_allocate0(). I'm
> shocked to hear that you and Andre
On Tue, Apr 22, 2025 at 4:12 AM Daniel Gustafsson
wrote:
> Do you mean that an interrupt handler will make DSA allocations? I don't
> think
> that would be something we'd want to allow regardless of this patch. Or did I
> misunderstand the above?
My primary concern about the patch is that
Proc
Hi,
On 2025-04-17 10:42:45 -0400, Robert Haas wrote:
> On Tue, Apr 15, 2025 at 6:11 AM Andres Freund wrote:
> > There very well could be a CFI - but it better be somewhere where the
> > in-memory state is consistent. Otherwise an error inside raised in the CFI
> > would lead the in-memory state i
> On 17 Apr 2025, at 16:42, Robert Haas wrote:
>
> On Tue, Apr 15, 2025 at 6:11 AM Andres Freund wrote:
>> There very well could be a CFI - but it better be somewhere where the
>> in-memory state is consistent. Otherwise an error inside raised in the CFI
>> would lead the in-memory state inconsi
On Tue, Apr 15, 2025 at 6:11 AM Andres Freund wrote:
> There very well could be a CFI - but it better be somewhere where the
> in-memory state is consistent. Otherwise an error inside raised in the CFI
> would lead the in-memory state inconsistent which then would cause problems
> when cleaning up
On Thu, Apr 10, 2025 at 4:05 PM Andres Freund wrote:
> I don't know of existing discussion, but it seems rather fundamental to me -
> if either DSA or memory contexts could be inconsistent at a CFI(), how could
> it possibly be safe to interrupt at that point? After all, after an error you
> need
Hi,
On 2025-04-14 10:03:28 -0400, Robert Haas wrote:
> On Thu, Apr 10, 2025 at 4:05 PM Andres Freund wrote:
> > I don't know of existing discussion, but it seems rather fundamental to me -
> > if either DSA or memory contexts could be inconsistent at a CFI(), how could
> > it possibly be safe to
Hi,
On 2025-04-10 09:31:00 -0400, Robert Haas wrote:
> On Tue, Apr 8, 2025 at 5:10 AM Daniel Gustafsson
> wrote:
> > Add function to get memory context stats for processes
>
> Apologies if this has already been discussed, but what is the argument
> that it is safe to do everything in ProcessGetM
On Tue, Apr 8, 2025 at 5:10 AM Daniel Gustafsson
wrote:
> Add function to get memory context stats for processes
Apologies if this has already been discussed, but what is the argument
that it is safe to do everything in ProcessGetMemoryContextInterrupt()
at an arbitrary CHECK_FOR_INTERRUPTS() cal
13 matches
Mail list logo
