From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUG] Possible occurrence of segfault in ecpg test |
Date: | 2024-12-11 21:00:32 |
Message-ID: | 524527.1733950832@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniil Davydov <3danissimo(at)gmail(dot)com> writes:
> Thus, if the program behaves in an unexpected way and the transaction
> is aborted before it executes the
> "select data1 into :recv_vlen_buf from test" query, dump_binary will
> refer to a null pointer. So, instead of an error
> message, the user will see a segfault.
> I think that in all such cases it is worth adding some checks into
> .pgc and .c files (like in attached patch)
I cannot get excited about changing this. In the first place,
this is hardly the only conceivable failure here --- for example,
if the query succeeds but returns only one row, the code still
segfaults. In the second place, this is just test code and any
sort of failure is as good as any other in terms of calling our
attention to a problem. In the third place, if we did want to
improve our standard of robustness for the ECPG tests, there are
probably many other places in them with similar issues. Making
that happen seems like a lot of work for little return. So I'm
inclined to just leave it alone.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-12-11 21:29:51 | Re: VACUUM cleaning of CF 2024-11 |
Previous Message | David Rowley | 2024-12-11 20:55:41 | Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE |