Hi, In the AIO patchset there are cases where we have to LOG failures inside a critical section. This is necessary because e.g. a buffer read might complete while we are waiting for a WAL write inside a critical section.
We can't just defer the log message, as the IO might end up being waited-on/completed-by another backend than the backend that issued the IO, so we'd defer logging issues until an effectively arbitrary later time. In general emitting a LOG inside a critical section isn't a huge issue - we made sure that elog.c has a reserve of memory to be able to log without crashing. However, the current message for buffer IO issues use relpath*() (ending up in a call to GetRelationPath()). Which in turn uses psprintf() to generate the path. Which in turn violates the no-memory-allocations-in-critical-sections rule, as the containing memory context will typically not have ->allowInCritSection == true. It's not obvious to me what the best way to deal with this is. One idea I had was to add an errrelpath() that switches to edata->assoc_context before calling relpath(), but that would end up leaking memory, as FreeErrorDataContents() wouldn't know about the allocation. Obviously we could add a version of GetRelationPath() that just prints into a caller provided buffer - but that's somewhat awkward API wise. A third approach would be to have a dedicated memory context for this kind of thing that's reset after logging the message - but that comes awkwardly close to duplicating ErrorContext. I wonder if we're lacking a bit of infrastructure here... Greetings, Andres Freund
