| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Yuqi Gu <Yuqi(dot)Gu(at)arm(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Optimize Arm64 crc32c implementation in Postgresql |
| Date: | 2018-05-03 04:48:29 |
| Message-ID: | 1644.1525322909@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Thu, May 3, 2018 at 4:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It strikes me also that, at least for debugging purposes, it's seriously
>> awful that you can't tell from outside what result this function got.
> I don't think *broken* CPUs are something we need to handle, are they?
I'm not worried so much about broken hardware as about scenarios like
"Munro got the magic constant wrong and nobody ever noticed", or more
likely "somebody broke it later and we didn't notice". We absolutely
do not expect the code path with function-returns-the-wrong-answer to be
taken, and I think it would be appropriate to complain loudly if it is.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-05-03 05:18:41 | Re: Optimize Arm64 crc32c implementation in Postgresql |
| Previous Message | Thomas Munro | 2018-05-03 04:31:13 | Re: Optimize Arm64 crc32c implementation in Postgresql |