|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
> + */
> 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.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|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.|