Robert Haas <robertmh...@gmail.com>
03:24 (6小时前)
发送至 我、 pgsql-hackers
On Wed, Aug 7, 2024 at 11:24 PM Xiaoran Wang <fanfuxiao...@gmail.com> wrote:
> When I use the 'pqmq' recently, I found some issues, just fix them.
>
> Allow the param 'dsm_segment *seg' to be NULL in function
> 'pq_redirect_to_shm_mq'. As sometimes the shm_mq is created
> in shared memory instead of DSM.
>. Under what circumstances does this happen?
I just create a shm_mq in shared memory, compared with DSM, it is easier.
And don't need to attach and detach to the DSM.
This shm_mq in shared memory can meet my requirement, which is used
in two different sessions, one session A dumps some information into
another
session B through the shm_mq. Session B is actually a monitor session,
user can
use it to monitor the state of slow queries, such as queries in session A.
Yes, I can choose to use DSM in such situation. But I think it's better
to let the 'pqmq'
to support the shm_mq not in DSM.
> Add function 'pq_leave_shm_mq' to allow the process to go
> back to the previous pq environment.
>. In the code as it currently exists, a parallel worker never has a
>. connected client, and it talks to a shm_mq instead. So there's no need
>. for this. If a backend needs to communicate with both a connected
> client and also a shm_mq, it probably should not use pqmq but rather
> decide explicitly which messages should be sent to the client and
> which to the shm_mq. Otherwise, it seems hard to avoid possible loss
> of protocol sync.
As described above, session B will send a signal to session A, then
session A handle the signal and send the message into the shm_mq.
The message is sent by pq protocol. So session A will firstly call
'pq_redirect_to_shm_mq' and then call 'pq_leave_shm_mq' to
continue to do its work.
Robert Haas <robertmh...@gmail.com> 于2024年8月9日周五 03:24写道：
> On Wed, Aug 7, 2024 at 11:24 PM Xiaoran Wang <fanfuxiao...@gmail.com>
> wrote:
> > When I use the 'pqmq' recently, I found some issues, just fix them.
> >
> > Allow the param 'dsm_segment *seg' to be NULL in function
> > 'pq_redirect_to_shm_mq'. As sometimes the shm_mq is created
> > in shared memory instead of DSM.
>
> Under what circumstances does this happen?
>
> > Add function 'pq_leave_shm_mq' to allow the process to go
> > back to the previous pq environment.
>
> In the code as it currently exists, a parallel worker never has a
> connected client, and it talks to a shm_mq instead. So there's no need
> for this. If a backend needs to communicate with both a connected
> client and also a shm_mq, it probably should not use pqmq but rather
> decide explicitly which messages should be sent to the client and
> which to the shm_mq. Otherwise, it seems hard to avoid possible loss
> of protocol sync.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
