Re: Teach pg_receivewal to use lz4 compression - Mailing list pgsql-hackers

From gkokolatos@pm.me
Subject Re: Teach pg_receivewal to use lz4 compression
Date
Msg-id UNDEJfRFUIxXIS78sze4y5e4EXRSOtFlXqFuzAYiE2KhcXBkogVxNprmyHDkGax1MON1tOzQUWjQ6PivDV9WKgzTnqEviVIEaX90ZeO9c9s=@pm.me
Whole thread Raw
In response to Re: Teach pg_receivewal to use lz4 compression  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Shouldn't postgres_fdw report warning when it gives up getting result from foreign server?
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side