Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

bootstrap.c

Blame
    • Tom Lane's avatar
      b006f4dd
      Prevent memory leaks from accumulating across printtup() calls. · b006f4dd
      Tom Lane authored
      Historically, printtup() has assumed that it could prevent memory leakage
      by pfree'ing the string result of each output function and manually
      managing detoasting of toasted values.  This amounts to assuming that
      datatype output functions never leak any memory internally; an assumption
      we've already decided to be bogus elsewhere, for example in COPY OUT.
      range_out in particular is known to leak multiple kilobytes per call, as
      noted in bug #8573 from Godfried Vanluffelen.  While we could go in and fix
      that leak, it wouldn't be very notationally convenient, and in any case
      there have been and undoubtedly will again be other leaks in other output
      functions.  So what seems like the best solution is to run the output
      functions in a temporary memory context that can be reset after each row,
      as we're doing in COPY OUT.  Some quick experimentation suggests this is
      actually a tad faster than the retail pfree's anyway.
      
      This patch fixes all the variants of printtup, except for debugtup()
      which is used in standalone mode.  It doesn't seem worth worrying
      about query-lifespan leaks in standalone mode, and fixing that case
      would be a bit tedious since debugtup() doesn't currently have any
      startup or shutdown functions.
      
      While at it, remove manual detoast management from several other
      output-function call sites that had copied it from printtup().  This
      doesn't make a lot of difference right now, but in view of recent
      discussions about supporting "non-flattened" Datums, we're going to
      want that code gone eventually anyway.
      
      Back-patch to 9.2 where range_out was introduced.  We might eventually
      decide to back-patch this further, but in the absence of known major
      leaks in older output functions, I'll refrain for now.
      b006f4dd
      History
      Prevent memory leaks from accumulating across printtup() calls.
      Tom Lane authored
      Historically, printtup() has assumed that it could prevent memory leakage
      by pfree'ing the string result of each output function and manually
      managing detoasting of toasted values.  This amounts to assuming that
      datatype output functions never leak any memory internally; an assumption
      we've already decided to be bogus elsewhere, for example in COPY OUT.
      range_out in particular is known to leak multiple kilobytes per call, as
      noted in bug #8573 from Godfried Vanluffelen.  While we could go in and fix
      that leak, it wouldn't be very notationally convenient, and in any case
      there have been and undoubtedly will again be other leaks in other output
      functions.  So what seems like the best solution is to run the output
      functions in a temporary memory context that can be reset after each row,
      as we're doing in COPY OUT.  Some quick experimentation suggests this is
      actually a tad faster than the retail pfree's anyway.
      
      This patch fixes all the variants of printtup, except for debugtup()
      which is used in standalone mode.  It doesn't seem worth worrying
      about query-lifespan leaks in standalone mode, and fixing that case
      would be a bit tedious since debugtup() doesn't currently have any
      startup or shutdown functions.
      
      While at it, remove manual detoast management from several other
      output-function call sites that had copied it from printtup().  This
      doesn't make a lot of difference right now, but in view of recent
      discussions about supporting "non-flattened" Datums, we're going to
      want that code gone eventually anyway.
      
      Back-patch to 9.2 where range_out was introduced.  We might eventually
      decide to back-patch this further, but in the absence of known major
      leaks in older output functions, I'll refrain for now.