On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > Did we ever consider the idea of using a new pg_stat_wal_activity_progress > view or something like that, using the backend_progress.c functionality? > I don't see it mentioned in the thread.
IMO, progress reporting works well on a running server and at the moment. The WAL recovery/replay can happen even before the server opens up for connections and the progress report view can't be used for later analysis like how much time the restoring WAL files from archive location took and also the WAL file names can't be reported in progress reporting mechanism (only integers columns, of course if required we can add text columns to pg_stat_get_progress_info). Having the recovery info in server logs might help. > It's not an *exact* fit, since this is not about one "command" being > executed by a "backend", but it seems a near enough fit, and it would > unobtrusive enough that we don't need to worry about the progress-update > rate or have a GUC to determine how frequently to update (with a gauge > that's heavily workload-dependant and is likely to make little sense to > some users -- consider differently-sized WAL segments, for one thing). I think reporting a long-running file processing operation (removing or syncing) within postgres is a generic problem (for snapshot, mapping, temporary (pgsql_tmp), temp relation files, old WAL file processing, WAL file processing during recovery etc.) and needs to be solved in two ways: 1) logging progress into server logs (which helps for analysis and report when the server isn't available for connections, crash recovery), a generic GUC log_file_processing_traffic = {none, medium, high} might help here (also proposed in [1]) and 2) pg_stat_file_processing_progress (extending progress reporting pg_stat_get_progress_info to have few text columns for current file name and directory path). Thoughts? Regards, Bharath Rupireddy.