On Wed, Aug 10, 2022 at 1:28 AM Andres Freund <and...@anarazel.de> wrote: > I assume this is trying to defend against some sort of deadlock by not > actually getting a cleanup lock (by passing get_cleanup_lock = true to > XLogReadBufferForRedoExtended()).
I had that thought too, but I don't *think* it's the case. This function acquires a lock on the oldest bucket page, then on the new bucket page. We could deadlock if someone who holds a pin on the new bucket page tries to take a content lock on the old bucket page. But who would do that? The new bucket page isn't yet linked from the metapage at this point, so no scan should do that. There can be no concurrent writers during replay. I think that if someone else has the new page pinned they probably should not be taking content locks on other buffers at the same time. So maybe we can just apply something like the attached. -- Robert Haas EDB: http://www.enterprisedb.com
hash-xlog-split-allocate-page-v1.patch
Description: Binary data
