Re: AIO v2.3 - Mailing list pgsql-hackers

From James Hunter
Subject Re: AIO v2.3
Date
Msg-id CAJVSvF5t63Q=j0uUT=8M0-3noTScn3M7rDYM1kY8T5K91agnyg@mail.gmail.com
Whole thread Raw
In response to Re: AIO v2.3  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Feb 11, 2025 at 1:44 PM Andres Freund <andres@anarazel.de> wrote:
>
...

> Alternatively we could make pgaio_batch_begin() basically start a critical
> section, but that doesn't seem like a good idea, because too much that needs
> to happen around buffered IO isn't compatible with critical sections.
>
>
> Does anybody see a need for batches to be nested? I'm inclined to think that
> that would be indicative of bugs and should therefore error/assert out.

Fwiw, in a similar situation in the past, I just blocked, waiting for
the in-flight batch to complete, before sending the next batch. So I
had something like:

void begin_batch(...)
{
  if (batch_in_progress())
    complete_batch(...);

  /* ok start the batch now */
}

In my case, batches were nested because different access methods
(e.g., Index) can call/trigger other access methods (Heap), and both
access methods might want to issue batch reads. However, the "inner"
access method  might not be aware of the "outer" access method.

For simplicity, then, I just completed the outer batch. Note that this
is not optimal for performance (because a nested batch ends up
stalling the outer batch), but it does keep the code simple...

James



pgsql-hackers by date:

Previous
From: Christophe Pettus
Date:
Subject: Cost-based delay for (other) maintenance operations
Next
From: Robert Haas
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring