> Really? How do you make sure that an error is detected if you are > dealing with multiple stats kinds where each one of them have their > own set of auxiliary files to write to, say: > - 2 custom stats kinds, each one uses one auxiliary file. > - Write of the stats at shutdown. > - Suddenly kind 1 fails, returns a status. Its auxiliary file is > removable due to the ferror(), the main stats file is also discarded. > > Kind 2 may not have the opportunity to mark its file as problematic, > meaning that it would be skipped at finish(STATS_WRITE) and left > around, especially if we are dealing with the most common scenarios of > an ENOSPC or an EROFS with all these files written on the same > partition, most likely the one of the root data folder.
.. and you just made me realize that there is an existing bug in cleanup. In the pgstat_write path, STATS_WRITE is passed unconditionally to finish() regardless of the outcome of the write to the core temp stats file, and in the pgstat_read path, the finish() is completely skipped in the case the core permanent stats file is missing. So, in both cases we need to track if the respective core files are in a proper state and if not pass STATS_DISCARD to finish(). See the attached: 0001 - reverts ed823da12891 0002 - Ensures that the callbacks receive the correct STATS_DISCARD when there is core file failures so the extensions can perform the proper cleanup. This is the existing cleanup handling bug. 0003 - Changes to_serialized_data to return a bool. It handles this case by removing the temp core stats file, but unlike v1 it does not need to do so by jumping to a new "error" block. -- Sami
v2-0001-Revert-Rename-routines-for-write-read-of-pgstats-.patch
Description: Binary data
v2-0003-pgstat-change-to_serialized_data-callback-to-retu.patch
Description: Binary data
v2-0002-pgstat-pass-STATS_DISCARD-to-finish-on-stats-file.patch
Description: Binary data
