| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: astreamer_lz4: fix bug of output pointer advancement in decompressor |
| Date: | 2026-03-05 01:42:42 |
| Message-ID: | CAEoWx2=RKW06zHFeObhp4Wq25L5nPq12xQDADUgY5BiXOLUzwA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 5, 2026 at 2:12 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Japin Li | 2026-03-05 01:57:48 | Re: Convert NOT IN sublinks to anti-joins when safe |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-03-05 01:35:57 | RE: Parallel Apply |