Re: What exactly is our CRC algorithm?
От | Heikki Linnakangas |
---|---|
Тема | Re: What exactly is our CRC algorithm? |
Дата | |
Msg-id | 54D792E6.3080500@vmware.com обсуждение исходный текст |
Ответ на | Re: What exactly is our CRC algorithm? (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Ответы |
Re: What exactly is our CRC algorithm?
Re: What exactly is our CRC algorithm? |
Список | 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? [1] http://www.postgresql.org/message-id/flat/CAAZKuFaNcf3=YtadkWwr8yHb+1axW2RepmQ2j8a9NNGkV7PN=w@mail.gmail.com. - Heikki
В списке pgsql-hackers по дате отправления: