| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Georgios Kokolatos <gkokolatos(at)pm(dot)me>, Magnus Hagander <magnus(at)hagander(dot)net>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Teach pg_receivewal to use lz4 compression |
| Date: | 2021-11-22 14:02:47 |
| Message-ID: | CA+TgmoaBnZqRQB=Wo7omo9rmDtn0rsJuPdLwwazmewxK2adc6A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 22, 2021 at 12:46 AM Jeevan Ladhe
<jeevan(dot)ladhe(at)enterprisedb(dot)com> wrote:
> Fair enough. But, still I have a doubt in mind what benefit would that
> really bring to us here, because we are immediately also freeing the
> lz4buf without using it anywhere.
Yeah, I'm also doubtful about that. If we're freeng the compression
context, we shouldn't need to guarantee that it's in any particular
state before doing so. Why would any critical cleanup be part of
LZ4F_compressEnd() rather than LZ4F_freeCompressionContext()? The
point of LZ4F_compressEnd() is to make sure all of the output bytes
get written, and it would be stupid to force people to write the
output bytes even when they've decided that they no longer care about
them due to some error.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2021-11-22 14:17:35 | Re: rename SnapBuild* macros in slot.c |
| Previous Message | Aleksander Alekseev | 2021-11-22 13:57:56 | Re: rand48 replacement |