Re: add function for creating/attaching hash table in DSM registry - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id CAA5RZ0so5s0Q6tyeCfovKYwO3sOQFwdAT5WVM688Ryy+toPthA@mail.gmail.com
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Sami Imseih <samimseih@gmail.com>)
Responses Re: add function for creating/attaching hash table in DSM registry
List pgsql-hackers
> It is not expected behavior IMO, and I still need to debug this a bit more,
> but it may be something outside the scope of this patch that the patch just
> surfaced.

It seems I got it backward. If the tranch is registered, then the wait event
name is the one of the tranche, in that case we will see the name of the
tranch suffixed with "_dsh". If the tranche is not registered, then the
wait event name is "extension". We can end up instrumenting with 2 different
wait event names, "extension" or the tranche name, for the same code path.
This looks broken to me, but I am not sure what could be done yet.
It should be taken up for discussion in a separate thread, as it's not
the fault of this patch.

Going back to the original point, DSMRegistryHash and DSMRegistryHash
are built-in, and those names are well-defined and actually refer to
waits related to the mechanism of registering a DSA or a HASH.
I think it will be odd to append "_dsh", but we should at minimum add
a comment in the GetNamedDSMHash explaining this.


--
Sami



pgsql-hackers by date:

Previous
From: Dimitrios Apostolou
Date:
Subject: [PATCH v2] parallel pg_restore: move offset-building phase to before forking
Next
From: Dimitrios Apostolou
Date:
Subject: [WIP PATCH v2] Implement "pg_restore --data-only --clean" as a way to skip WAL