From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Avoid overhead with fprintf related functions |
Date: | 2022-09-09 13:45:37 |
Message-ID: | CAEudQAoXozYNsx3T-PZFk-QraRKYHRRarOhF4C2GuTfrct3g_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Based on work in [1].
According to https://cplusplus.com/reference/cstdio/fprintf/
The use of fprintf is related to the need to generate a string based on a
format, which should be different from "%s".
Since fprintf has overhead when parsing the "format" parameter, plus all
the trouble of checking the va_arg parameters.
I think this is one of the low fruits available and easy to reap.
By replacing fprintf with its equivalents, fputs and fputc,
we avoid overhead and increase security [2] and [3].
The downside is a huge big churm, which unfortunately will occur.
But, IHMO, I think the advantages are worth it.
Note that behavior remains the same, since fputs and fputc do not change
the expected behavior of fprintf.
A small performance gain is expected, mainly for the client, since there
are several occurrences in some critical places, such as
(usr/src/fe_utils/print.c).
Patch attached.
This pass check-world.
regards,
Ranier Vilela
[1]
https://www.postgresql.org/message-id/CAApHDvp2THseLvCc%2BTcYFBC7FKHpHTs1JyYmd2JghtOVhb5WGA%40mail.gmail.com
[2]
https://stackoverflow.com/questions/20837989/fprintf-stack-buffer-overflow
[3]
https://bufferoverflows.net/format-string-vulnerability-what-when-and-how/
Attachment | Content-Type | Size |
---|---|---|
fprintf_fixes.patch | application/octet-stream | 67.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-09-09 13:56:42 | Re: why can't a table be part of the same publication as its schema |
Previous Message | Melih Mutlu | 2022-09-09 13:41:07 | Re: Summary function for pg_buffercache |