From: | Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] Imporve pqmq |
Date: | 2024-08-13 07:38:55 |
Message-ID: | CAGjhLkNVeZDeqRWa3=nj+H0voJewX1VjyxfH5DrmJB0HefyMsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> 于2024年8月13日周二 00:28写道:
> On Thu, Aug 8, 2024 at 10:27 PM Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com>
> wrote:
> > > 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.
>
> In this kind of use case, there is really no reason to use the libpq
> protocol at all. You would be better off just using a shm_mq directly,
> and then you don't need this patch. See tqueue.c for an example of
> such a coding pattern.
>
Thanks for your reply and suggestion, I will look into that.
>
> Using pqmq is very error-prone here. In particular, if a backend
> unexpectedly hits an ERROR while the direct is in place, the error
> will be sent to the other session rather than to the connected client.
> This breaks wire protocol synchronization.
>
Yes, I found this problem too. Between the 'pq_beginmessage' and
'pq_endmessage',
any log should not be emitted to the client as it will be sent to the shm_mq
instead of client. Such as I sometimes set client_min_messages='debug1'
in psql, then it will go totally wrong. It maybe better to firstly write
the 'msg'
into a StringInfoData, then send the 'msg' by libpq.
I agree that it is not good way to communicate between tow sessions.
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
--
Best regards !
Xiaoran Wang
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2024-08-13 07:49:37 | Re: Optimize mul_var() for var1ndigits >= 8 |
Previous Message | cca5507 | 2024-08-13 07:32:42 | Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state |