Hi,

On 2022-03-16 21:47:49 +0000, Imseih (AWS), Sami wrote:
> From 85c47dfb3bb72f764b9052e74a7282c19ebd9898 Mon Sep 17 00:00:00 2001
> From: "Sami Imseih (AWS)" <sims...@amazon.com>
> Date: Wed, 16 Mar 2022 20:39:52 +0000
> Subject: [PATCH 1/1] Add infrastructure for parallel progress reporting
> 
> Infrastructure to allow a parallel worker to report
> progress. In a PARALLEL command, the workers and
> leader can report progress using a new pgstat_progress
> API.

What happens if we run out of memory for hashtable entries?


> +void
> +pgstat_progress_update_param_parallel(int leader_pid, int index, int64 val)
> +{
> +     ProgressParallelEntry *entry;
> +     bool found;
> +
> +     LWLockAcquire(ProgressParallelLock, LW_EXCLUSIVE);
> +
> +     entry = (ProgressParallelEntry *) hash_search(ProgressParallelHash, 
> &leader_pid, HASH_ENTER, &found);
> +
> +     /*
> +      * If the entry is not found, set the value for the index'th member,
> +      * else increment the current value of the index'th member.
> +      */
> +     if (!found)
> +             entry->st_progress_param[index] = val;
> +     else
> +             entry->st_progress_param[index] += val;
> +
> +     LWLockRelease(ProgressParallelLock);
> +}

I think that's an absolute no-go. Adding locking to progress reporting,
particularly a single central lwlock, is going to *vastly* increase the
overhead incurred by progress reporting.

Greetings,

Andres Freund


Reply via email to