[redirected to -hackers]

Tom Lane wrote:
Another thing that needs to be looked at carefully is how much memory
write_csvlog() eats. I'm a little bit concerned about whether it will
result in infinite recursion when our backs are against the wall and
we only have the original 8K in ErrorContext to work in. (We could
increase that figure if need be, but we need to know by how much.)


I think we can make a saving by rearranging the end of
send_message_to_server_log() so we can call pfree(buf.data) before we
call write_csvlog(). We can probably make a further saving by changing
how we put the CSV-escaped error message on the end of the buffer we
send down the pipe. I will look into those.

If these prove difficult, I'd say 24K would put us in an equivalent
position (two extra copies of the error message plus change). Even so,
I'm inclined to say that 8K is very tight. It might be enough for very
small startup messages, but is the context size likely to stay at 8K for
non-trivial uses? A single logged complex query or function body would
easily blow it.

cheers

andrew

Search Discussions

  • Tom Lane at Aug 19, 2007 at 4:59 pm

    Andrew Dunstan writes:
    If these prove difficult, I'd say 24K would put us in an equivalent
    position (two extra copies of the error message plus change). Even so,
    I'm inclined to say that 8K is very tight.
    We really only care about being able to deliver an "out of memory during
    error recovery" message within that space. So yes, you can assume the
    message text isn't huge and there isn't any add-on context info to worry
    about. But there could be localization and/or encoding translation costs.

    regards, tom lane
  • Andrew Dunstan at Aug 20, 2007 at 1:41 am

    Tom Lane wrote:
    Andrew Dunstan <andrew@dunslane.net> writes:
    If these prove difficult, I'd say 24K would put us in an equivalent
    position (two extra copies of the error message plus change). Even so,
    I'm inclined to say that 8K is very tight.
    We really only care about being able to deliver an "out of memory during
    error recovery" message within that space. So yes, you can assume the
    message text isn't huge and there isn't any add-on context info to worry
    about. But there could be localization and/or encoding translation costs.

    Well, the attached small patch should reduce the memory impact
    substantially. Not sure whether you think that's sufficient, or you want
    to take it further.

    cheers

    andrew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 19, '07 at 4:47p
activeAug 20, '07 at 1:41a
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Andrew Dunstan: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2021 Grokbase