Re: libpq compression (part 2)

From: Andrey Borodin <amborodin86(at)gmail(dot)com>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Daniil Zakhlystov <usernamedt(at)yandex-team(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Subject: Re: libpq compression (part 2)
Date: 2022-11-15 03:44:24
Message-ID: CAAhFRxicA=0EBxhJfJJLkP62BKX0_UUWM4uaYj8Gwk54r48TiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 12, 2022 at 8:04 PM Andrey Borodin <amborodin86(at)gmail(dot)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 Content-Type Size
boom.sql application/octet-stream 16.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-11-15 04:49:16 Re: Suppressing useless wakeups in walreceiver
Previous Message Thomas Munro 2022-11-15 03:26:50 Re: Assertion failure in SnapBuildInitialSnapshot()