Horton

Re: astreamer_lz4: fix bug of output pointer advancement in decompressor

Chao Li <li.evan.chao@gmail.com>

View thread View on postgr.es
From: Chao Li <li.evan.chao@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2026-03-05T01:42:42Z
Lists: pgsql-hackers 
On Thu, Mar 5, 2026 at 2:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I wrote:
> > I suspect whoever wrote this thought pg_log_error is equivalent
> > to elog(ERROR), but it's not; it just prints a message.  It seems
> > highly unlikely to me that continuing onwards will result in a
> > good outcome.  I'm a bit inclined to s/pg_log_error/pg_fatal/
> > throughout these files, at least in places where there's no
> > visible effort to handle the error.
>
> After looking through fe_utils, pg_dump, pg_basebackup, and
> pg_verifybackup, I found the attached places that seem to
> need cleanup.  There are a couple other places where we
> are not treating failures as fatal, but those seem intentional,
> eg not fatal'ing on close() failure for an input file.
>
>                         regards, tom lane
>
>
I also thought pg_log_error behaves the same way as elog(ERROR). Noted now.

The cleanup looks good to me. I also did a broader search, and didn't find
a more similar place to clean up.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Commits

  1. Exit after fatal errors in client-side compression code.

  2. Fix yet another bug in archive streamer with LZ4 decompression.