pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). 6+ messages / 1 participants [nested] [flat]
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a7f95859ef7763ffb7f87894553ab25f5268f33c Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3977bd2985de8c5e4b8b00f67dfec28dcfb343c9 Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/644b7d686e4d4173265c01ef11957a0bee1f6a2c Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2226a2e266dbabc5597fff5f624b3fcd71ce5fa8 Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f864a4cdfcec1de50ef969772a59daeed39c4a1d Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). @ 2025-02-16 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-02-16 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Coverity complained that we weren't doing that, and it's right. This fix just makes fmtIdEnc() honor the general convention that OOM causes a PQExpBuffer to become marked "broken", without any immediate error. In the pretty-unlikely case that we actually did hit OOM here, the end result would be to return an empty string to the caller, probably resulting in invalid SQL syntax in an issued command (if nothing else went wrong, which is even more unlikely). It's tempting to throw an "out of memory" error if the buffer becomes broken, but there's not a lot of point in doing that only here and not in hundreds of other PQExpBuffer-using places in pg_dump and similar callers. The whole issue could do with some non-time-crunched redesign, perhaps. This is a followup to the fixes for CVE-2025-1094, and should be included if cherry-picking those fixes. Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9f052613e44606773aead07e2cd9e22710d7fbc5 Modified Files -------------- src/fe_utils/string_utils.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-02-16 17:46 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us> 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us> 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us> 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us> 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us> 2025-02-16 17:46 pgsql: In fmtIdEnc(), handle failure of enlargePQExpBuffer(). Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox