From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tels <nospam-pg-abuse(at)bloodgate(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [POC] Faster processing at Gather node |
Date: | 2018-03-29 16:18:43 |
Message-ID: | 20180329161843.GC16165@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 2, 2018 at 05:21:28PM -0500, Tels wrote:
> Hello Robert,
>
> On Fri, March 2, 2018 12:22 pm, Robert Haas wrote:
> > On Wed, Feb 28, 2018 at 10:06 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> > wrote:
> >> [ latest patches ]
> >
> > Committed. Thanks for the review.
>
> Cool :)
>
> There is a typo, tho:
>
> + /*
> + * If the counterpary is known to have attached, we can read mq_receiver
> + * without acquiring the spinlock and assume it isn't NULL. Otherwise,
> + * more caution is needed.
> + */
>
> s/counterpary/counterparty/;
>
> Sorry, only noticed while re-reading the thread.
>
> Also, either a double space is missing, or one is too many:
>
> + /*
> + * Separate prior reads of mq_ring from the increment of mq_bytes_read
> + * which follows. Pairs with the full barrier in shm_mq_send_bytes(). We
> + * only need a read barrier here because the increment of mq_bytes_read is
> + * actually a read followed by a dependent write.
> + */
>
> (" Pairs ..." vs. ". We only ...")
>
> Best regards,
Change applied with the attached patch.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachment | Content-Type | Size |
---|---|---|
shm.diff | text/x-diff | 1.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Catalin Iacob | 2018-03-29 16:20:00 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Previous Message | Alvaro Herrera | 2018-03-29 16:04:06 | Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour. |