Re: libpq compression (part 2) - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: libpq compression (part 2)
Date
Msg-id CAAhFRxicA=0EBxhJfJJLkP62BKX0_UUWM4uaYj8Gwk54r48TiA@mail.gmail.com
Whole thread Raw
In response to Re: libpq compression (part 2)  (Andrey Borodin <amborodin86@gmail.com>)
Responses Re: libpq compression (part 2)
List pgsql-hackers
On Sat, Nov 12, 2022 at 8:04 PM Andrey Borodin <amborodin86@gmail.com> wrote:
>
> While testing patch some more I observe unpleasant segfaults:
>
> #27 0x000000000b08fda2 in lz4_decompress (d_stream=0x18cf82a0,
> src=0x7feae4fa505d, src_size=92,
> (gdb) select-frame 27
> (gdb) info locals
> ds = 0x18cf82a0
> decPtr = 0x18cf8aec ""
> decBytes = -87
>

I've debugged the stuff and the problem resulted to be in wrong
message limits for Lz4 compression
+#define MESSAGE_MAX_BYTES 819200
instead of
+#define MESSAGE_MAX_BYTES 8192

Other codecs can utilize continuation of the decompression stream
using ZS_DATA_PENDING, while Lz4 cannot do this. I was going to
produce quickfix for all my lz4 findings, but it occured to me that a
patchset needs a heavy rebase. If no one shows up to fix it I'll do
that in one of the coming weekends. Either way here's a reproducer for
the coredump:
psql 'compression=lz4' -f boom.sql

Thanks!

Best regards, Andrey Borodin.

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Assertion failure in SnapBuildInitialSnapshot()
Next
From: Nathan Bossart
Date:
Subject: Re: Suppressing useless wakeups in walreceiver