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

tqueue.c

Blame
    • Tom Lane's avatar
      a9ed875f
      Code review for tqueue.c: fix memory leaks, speed it up, other fixes. · a9ed875f
      Tom Lane authored
      When doing record typmod remapping, tqueue.c did fresh catalog lookups
      for each tuple it processed, which was pretty horrible performance-wise
      (it seemed to about halve the already none-too-quick speed of bulk reads
      in parallel mode).  Worse, it insisted on putting bits of that data into
      TopMemoryContext, from where it never freed them, causing a
      session-lifespan memory leak.  (I suppose this was coded with the idea
      that the sender process would quit after finishing the query ---
      but the receiver uses the same code.)
      
      Restructure to avoid repetitive catalog lookups and to keep that data
      in a query-lifespan context, in or below the context where the
      TQueueDestReceiver or TupleQueueReader itself lives.
      
      Fix some other bugs such as continuing to use a tupledesc after
      releasing our refcount on it.  Clean up cavalier datatype choices
      (typmods are int32, please, not int, and certainly not Oid).  Improve
      comments and error message wording.
      a9ed875f
      History
      Code review for tqueue.c: fix memory leaks, speed it up, other fixes.
      Tom Lane authored
      When doing record typmod remapping, tqueue.c did fresh catalog lookups
      for each tuple it processed, which was pretty horrible performance-wise
      (it seemed to about halve the already none-too-quick speed of bulk reads
      in parallel mode).  Worse, it insisted on putting bits of that data into
      TopMemoryContext, from where it never freed them, causing a
      session-lifespan memory leak.  (I suppose this was coded with the idea
      that the sender process would quit after finishing the query ---
      but the receiver uses the same code.)
      
      Restructure to avoid repetitive catalog lookups and to keep that data
      in a query-lifespan context, in or below the context where the
      TQueueDestReceiver or TupleQueueReader itself lives.
      
      Fix some other bugs such as continuing to use a tupledesc after
      releasing our refcount on it.  Clean up cavalier datatype choices
      (typmods are int32, please, not int, and certainly not Oid).  Improve
      comments and error message wording.