Re: [patch] Imporve pqmq

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] Imporve pqmq
Date: 2024-08-12 16:28:29
Message-ID: CA+TgmoY7eA+iwRF=nMT20xreDGny+1M46cyhdYuKVo8HYfLZCA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-08-12 17:21:04 Re: Recent 027_streaming_regress.pl hangs
Previous Message Tomas Vondra 2024-08-12 16:25:34 Re: Add support for (Var op Var) clause in extended MCV statistics