From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory error in src/backend/replication/logical/origin.c |
Date: | 2017-11-26 22:31:08 |
Message-ID: | 91DFFD71-4D34-488B-B49A-B9F863CB976A@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Nov 26, 2017, at 10:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> bool nulls[Natts_pg_replication_origin];
>> memset(&nulls, 0, sizeof(nulls));
>
>> around lines 277 through 303. Patch below.
>
> AFAIK this is not a bug, though I agree that dropping the "&" is probably
> better style. The reason is that applying "&" to an undecorated array
> name is basically a no-op, because without "&" the array name would decay
> to a pointer anyway. With "&", the address-taking is explicit, but you
> still get a pointer to the array, not a pointer to some pointer to the
> array. Ain't C fun?
Thanks for the refresher on C madness.
mark
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-11-26 22:56:32 | Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables |
Previous Message | Tom Lane | 2017-11-26 20:19:41 | Re: [HACKERS] More stats about skipped vacuums |