Re: [patch] Imporve pqmq

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

In response to

Browse pgsql-hackers by date

  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