Hi, On 2020-10-29 11:17:29 -0700, Andres Freund wrote: > The code does IO while holding the buffer mapping lock. That seems > *entirely* unacceptable to me. That basically locks 1/128 of shared > buffers against concurrent mapping changes, while reading data that is > likely not to be on disk? Seriously?
Also, uh, I don't think the locking of the buffer table provides you with the full guarantees CheckBuffer() seems to assume: * Check the state of a buffer without loading it into the shared buffers. To * avoid torn pages and possible false positives when reading data, a shared * LWLock is taken on the target buffer pool partition mapping, and we check * if the page is in shared buffers or not. An I/O lock is taken on the block * to prevent any concurrent activity from happening. this doesn't actually prevent all concurrent write IO, unless you hold an appropriate lock on the relation. There's a few places that use smgrwrite()/smgrextend() to write out data bypassing shared buffers. Maybe that isn't a problem for the uses of CheckBuffer() is envisioned for, but that'd need a pretty detailed explanation as to when it's safe to use CheckBuffer() for which blocks. Greetings, Andres Freund
