It should not be true - the data sender create DSM and fills it. Then set caller slot and send signal to caller. Caller can free DSM any time, because data sender send newer touch it.
But the requester can timeout on waiting for reply and exit before it sees the reply DSM. Actually, I now don't even think a backend can free the DSM it has not created. First it will need to attach it, effectively increasing the refcount, and upon detach it will only decrease the refcount, but not actually release the segment...
I am afraid so it has not simple and nice solution - when data sender will wait for to moment when data are received, then we have same complexity like we use shm_mq.
Isn't better to introduce new background worker with responsibility to clean orphaned DSM?
I'm not thrilled by this idea.
We don't even need a worker to do that, as leaked segments are reported by the backend itself upon transaction commit (see ResourceOwnerReleaseInternal), e.g:
WARNING: dynamic shared memory leak: segment 808539725 still referenced
Still I believe relying on some magic cleanup mechanism and not caring about managing the shared memory properly is not the way to go.
It was one my idea too, to check shared memory on exit. The disadvantage is clean - some times you can wait too long - although the very practical limit for session is about 2h.
