Re: Teach pg_receivewal to use lz4 compression
От | gkokolatos@pm.me |
---|---|
Тема | Re: Teach pg_receivewal to use lz4 compression |
Дата | |
Msg-id | UNDEJfRFUIxXIS78sze4y5e4EXRSOtFlXqFuzAYiE2KhcXBkogVxNprmyHDkGax1MON1tOzQUWjQ6PivDV9WKgzTnqEviVIEaX90ZeO9c9s=@pm.me обсуждение исходный текст |
Ответ на | Re: Teach pg_receivewal to use lz4 compression (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, November 19th, 2021 at 3:07 AM, Michael Paquier <michael@paquier.xyz> wrote: > On Thu, Nov 18, 2021 at 07:54:37PM +0530, Jeevan Ladhe wrote: > > > In dir_open_for_write() I observe that we are writing the header > > and then calling LZ4F_compressEnd() in case there is an error > > while writing the buffer to the file, and the output buffer of > > LZ4F_compressEnd() is not written anywhere. Why should this be > > necessary? To flush the contents of the internal buffer? But, then we > > are calling LZ4F_freeCompressionContext() immediately after the > > LZ4F_compressEnd() call. I might be missing something, will be > > happy to get more insights. > > My concern here was symmetry, where IMO it makes sense to have a > compressEnd call each time there is a successful compressBegin call > done for the LZ4 state data, as there is no way to know if in the > future LZ4 won't change some of its internals to do more than just an > internal flush. Agreed. Although the library does provide an interface for simply flushing contents, it also assumes that each initializing call will have a finilizing call. If my memory serves me right, earlier versions of the patch, did not have this summetry, but that got ammended. Cheers, //Georgios > --- > Michael
В списке pgsql-hackers по дате отправления: