Hi,
On 2023-04-24 21:29:48 -0400, Melanie Plageman wrote:
> 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.
The number of blocks is the right thing IMO. The rest is just some
micro-optimization.
> 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 think it'd be wrong on performance grounds ;). We could add an assertion to
ScheduleBufferTagForWriteback(), I guess, to document that fact?
> 3) Should any restrictions be added to pgstat_tracks_io_object() or
> pgstat_tracks_io_op()? I couldn't think of any backend types or IO
> contexts which would not do writeback as a rule. Also, though we don't
> do writeback for temp tables now, it isn't nonsensical to do so. In
> this version, I didn't add any restrictions.
I think the temp table restriction could be encoded for now, I don't forsee
that changing anytime soon.
About other restrictions: Anything that triggers catalog access can trigger
buffers to be written back. Checkpointer and bgwriter don't do catalog access,
but have explicit writeback calls. WAL receiver, WAL writer, syslogger and
archiver are excluded on a backend type basis. I think the startup process
will use the normal backend logic, and thus also trigger writebacks?
Greetings,
Andres Freund
