| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>, ilia(dot)kashintsev(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19612: SEGV in ParseConfigFp() in guc-file.l |
| Date: | 2026-08-16 22:26:26 |
| Message-ID: | aoI5El4tC-uBbU2c@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, Aug 16, 2026 at 10:32:14AM -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > It seems to me that we should also have a `goto cleanup` if
> > yylex_init() fails, also pointing at d663f150b5ed that has switched
> > the scanner to be reentrant where yylex_init() has been added.
>
> Yeah. The other thing not being covered here is the possibility
> that yy_create_buffer fails and returns NULL.
Are you worried about possible future changes on the flex side? If I
read src/c99-flex.skl in the flex repo, yy_create_buffer() always uses
yypanic(), which would trigger the sigjmp. yylex_init() just sets an
ENOMEM and returns NULL.
Saying that, I can see your point in making our code more defensive,
on the assumption that upstream could change things, or based on the
assumption that we would catch failures if the error handling in
guc-file.l is touched one way or another.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zexin Li | 2026-08-16 23:36:01 | Re: BUG #19583: macaddr input accepts octet fields longer than 8 hex digits |
| Previous Message | Andrey Borodin | 2026-08-16 16:01:18 | Re: BUG #19620: pg_class index corruption caused by statement_timeout during VACUUM FULL |