Re: astreamer_lz4: fix bug of output pointer advancement in decompressor - Mailing list pgsql-hackers

From Chao Li
Subject Re: astreamer_lz4: fix bug of output pointer advancement in decompressor
Date
Msg-id CAEoWx2=RKW06zHFeObhp4Wq25L5nPq12xQDADUgY5BiXOLUzwA@mail.gmail.com
Whole thread
In response to Re: astreamer_lz4: fix bug of output pointer advancement in decompressor  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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/

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Parallel Apply
Next
From: Japin Li
Date:
Subject: Re: Convert NOT IN sublinks to anti-joins when safe