On Mon, Apr 24, 2023 at 9:29 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I've yet to cook up a client backend test case (e.g. with COPY). I've taken
> that as a todo.
It was trivial to see client backend writebacks in almost any scenario
once I set backend_flush_after. I wonder if it is worth mentioning the
various "*flush_after" gucs in the docs?
> I have a few outstanding questions:
>
> 1) Does it make sense for writebacks to count the number of blocks for
> which writeback was requested or the number of calls to smgrwriteback() or
> the number of actual syscalls made? We don't actually know from outside
> of mdwriteback() how many FileWriteback() calls we will make.
So, in the attached v3, I've kept the first method: writebacks are the
number of blocks which the backend has requested writeback of. I'd like
it to be clear in the docs exactly what writebacks are (so that people
know not to add them together with writes or something like that). I
made an effort but could use further docs review.
> 2) I'm a little nervous about not including IOObject in the writeback
> context. Technically, there is nothing stopping local buffer code from
> calling IssuePendingWritebacks(). Right now, local buffer code doesn't
> do ScheduleBufferTagForWriteback(). But it doesn't seem quite right to
> hardcode in IOOBJECT_RELATION when there is nothing wrong with
> requesting writeback of local buffers (AFAIK). What do you think?
I've gone ahead and added IOObject to the WritebackContext.
- Melanie