Re: snprintf.c hammering memset()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
Pg Hackers <pgsql-hackers@postgresql.org>,
Mateusz Guzik <mjguzik@gmail.com>
Date: 2018-10-02T00:57:34Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2018-10-01 20:19:16 -0400, Tom Lane wrote: >> That patch takes the memset out of the main line, but it'd still be >> a performance problem for formats using argument reordering; and the >> stack-space concern would remain the same. > What I mean is that it shouldn't be that hard to only zero out the > portions of the array that are actually used, and thus could refrain > from introducing the limit. Well, we use the zeroing exactly to detect which entries have been used. Probably there's another way, but I doubt it'd be faster. In any case, the stack-space-consumption problem remains, and IMO that is a *far* greater concern than the cycles. Keep in mind that we'll be calling this code when we have already hit our stack space consumption limit. I'm a bit surprised that we've not seen any buildfarm members fall over in the error recursion test. We have not designed the system on the assumption that ereport() could eat half a meg of stack. regards, tom lane
Commits
-
Set snprintf.c's maximum number of NL arguments to be 31.
- dee848810d8a 9.5.15 landed
- d5895717e000 9.6.11 landed
- a5b46fc66dfb 9.4.20 landed
- a051c19c3cf4 11.0 landed
- 6483381a4d0b 10.6 landed
- 625b38ea0e98 12.0 landed
- 4ed6dc7d4b33 9.3.25 landed