From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: What exactly is our CRC algorithm? |
Date: | 2015-02-08 16:46:30 |
Message-ID: | 54D792E6.3080500@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/09/2015 10:32 AM, Abhijit Menon-Sen wrote:
> 1. The slicing-by-8 patch contains numerous changes:
With this patch, CALC_CRC32C is no longer a pure macro, but includes a
function call. That means that you can no longer just #include pg_crc.h
and pg_crc_tables.h in an external program. We made that arrangement
with two header files in 2012 [1], and added src/port/pg_crc.c which
just #includes pg_crc_tables.h, so that the backend and frontend
programs that use libpgport will have just one copy of the tables.
Now that there's some actual code in pg_crc.c, I think we have to just
give up on being able to get the CRC implementation without libpgport.
It was a nice thought, but I doubt there are any programs out there that
would have a problem with that. Anything that wants to read the WAL
needs xlogreader.c anyway.
But actually, we should now move pg_crc.c to src/common. It was a bit of
a hack to have it in src/port in the first place, because it has nothing
to do with portability, but src/common didn't exist back then. Now it does.
So I propose to move pg_crc.c to src/common, and move the tables from
pg_crc_tables.h directly to pg_crc.c. Thoughts?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-02-08 16:48:26 | Re: What exactly is our CRC algorithm? |
Previous Message | Noah Misch | 2015-02-08 16:31:20 | Re: assessing parallel-safety |