From: | James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
Subject: | Re: AIO v2.3 |
Date: | 2025-02-12 20:26:45 |
Message-ID: | CAJVSvF5t63Q=j0uUT=8M0-3noTScn3M7rDYM1kY8T5K91agnyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 11, 2025 at 1:44 PM Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Anton A. Melnikov | 2025-02-12 20:42:32 | Re: Change GUC hashtable to use simplehash? |
Previous Message | Christophe Pettus | 2025-02-12 20:11:21 | Cost-based delay for (other) maintenance operations |