On 4/2/26 06:00, Alexander Lakhin wrote: > Hello Tom and Tomas, > > 01.04.2026 23:20, Tom Lane wrote: >> Alexander Lakhin <[email protected]> writes: >>> I think this can explain slow CommitTransactionCommand() and why it >>> happens not every time. Regarding other animals, I guess they can >>> experience the same bumps but not exceeding 5 seconds (50 tries). Thus, >>> from my understanding, for the failure to happen, we need to have slow >>> storage and initialize_worker_spi() -> CommitTransactionCommand() reaching >>> XLogFileClose(). >> So, it remains not very clear why only widowbird is showing this >> failure, but I think we can safely take away the bottom-line >> conclusion that hard-wiring a maximum wait of 5s in >> CountOtherDBBackends() was not a great idea. > > There also were two failures from jay: [1], [2], but yes, widowbird is > getting more and more consistent in that aspect: [3], probably because > of the storage (SD card?) degradation. >
Jay is a regular machine, 2-core VM hosted at a university, so not very powerful but was running for years just fine and seems to be healthy. > Tomas, maybe you could check if the write speed is more or less acceptable > there? > Will do. I'll wait for the tests to complete on widowbird, and will do some testing on the storage (it's running from a flash drive, not SD card, and I saw stuff in dmesg when it was dying in the past - but now it's clean). regards -- Tomas Vondra
