Re: Shmem queue is not flushed if receiver is not yet attached
От | Japin Li |
---|---|
Тема | Re: Shmem queue is not flushed if receiver is not yet attached |
Дата | |
Msg-id | MEYP282MB1669604F37576E1D3739826DB6D69@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Shmem queue is not flushed if receiver is not yet attached (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Shmem queue is not flushed if receiver is not yet attached
|
Список | pgsql-hackers |
On Tue, 24 May 2022 at 23:05, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 17, 2022 at 3:13 AM Pavan Deolasee <pavan.deolasee@gmail.com> wrote: >> While testing on the current PG master, I noticed a problem between backends communicating over a shared memory queue.I think `shm_mq_sendv()` fails to flush the queue, even if `force_flush` is set to true, if the receiver is not yetattached to the queue. This simple fix solves the problem for me. >> >> On another note, `shm_mq.h` declares `shm_mq_flush()`, but I don't see it being implemented. Maybe just a leftover fromthe previous work? Though it seems useful to implement that API. > > I think that this patch is basically correct, except that it's not > correct to set mqh_counterparty_attached when receiver is still NULL. > Here's a v2 where I've attempted to correct that while preserving the > essence of your proposed fix. > > I'm not sure that we need a shm_mq_flush(), but we definitely don't > have one currently, so I've also adjusted your patch to remove the > dead prototype. > > Please let me know your thoughts on the attached. > > Thanks, Hi, I have a problem that is also related to shmem queue [1], however, I cannot reproduce it. How did you reproduce this problem? [1] https://www.postgresql.org/message-id/MEYP282MB1669C8D88F0997354C2313C1B6CA9%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-hackers по дате отправления: