| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| 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-04 18:12:48 |
| Message-ID: | 1538177.1772647968@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-exit-after-pg_log_error.patch | text/x-diff | 6.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-04 18:45:35 | Re: Fix errno handling in popen_check() to avoid false error reports |
| Previous Message | Fujii Masao | 2026-03-04 17:46:50 | Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record |