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

cluster.c

Blame
    • Alvaro Herrera's avatar
      801c2dc7
      Separate multixact freezing parameters from xid's · 801c2dc7
      Alvaro Herrera authored
      Previously we were piggybacking on transaction ID parameters to freeze
      multixacts; but since there isn't necessarily any relationship between
      rates of Xid and multixact consumption, this turns out not to be a good
      idea.
      
      Therefore, we now have multixact-specific freezing parameters:
      
      vacuum_multixact_freeze_min_age: when to remove multis as we come across
      them in vacuum (default to 5 million, i.e. early in comparison to Xid's
      default of 50 million)
      
      vacuum_multixact_freeze_table_age: when to force whole-table scans
      instead of scanning only the pages marked as not all visible in
      visibility map (default to 150 million, same as for Xids).  Whichever of
      both which reaches the 150 million mark earlier will cause a whole-table
      scan.
      
      autovacuum_multixact_freeze_max_age: when for cause emergency,
      uninterruptible whole-table scans (default to 400 million, double as
      that for Xids).  This means there shouldn't be more frequent emergency
      vacuuming than previously, unless multixacts are being used very
      rapidly.
      
      Backpatch to 9.3 where multixacts were made to persist enough to require
      freezing.  To avoid an ABI break in 9.3, VacuumStmt has a couple of
      fields in an unnatural place, and StdRdOptions is split in two so that
      the newly added fields can go at the end.
      
      Patch by me, reviewed by Robert Haas, with additional input from Andres
      Freund and Tom Lane.
      801c2dc7
      History
      Separate multixact freezing parameters from xid's
      Alvaro Herrera authored
      Previously we were piggybacking on transaction ID parameters to freeze
      multixacts; but since there isn't necessarily any relationship between
      rates of Xid and multixact consumption, this turns out not to be a good
      idea.
      
      Therefore, we now have multixact-specific freezing parameters:
      
      vacuum_multixact_freeze_min_age: when to remove multis as we come across
      them in vacuum (default to 5 million, i.e. early in comparison to Xid's
      default of 50 million)
      
      vacuum_multixact_freeze_table_age: when to force whole-table scans
      instead of scanning only the pages marked as not all visible in
      visibility map (default to 150 million, same as for Xids).  Whichever of
      both which reaches the 150 million mark earlier will cause a whole-table
      scan.
      
      autovacuum_multixact_freeze_max_age: when for cause emergency,
      uninterruptible whole-table scans (default to 400 million, double as
      that for Xids).  This means there shouldn't be more frequent emergency
      vacuuming than previously, unless multixacts are being used very
      rapidly.
      
      Backpatch to 9.3 where multixacts were made to persist enough to require
      freezing.  To avoid an ABI break in 9.3, VacuumStmt has a couple of
      fields in an unnatural place, and StdRdOptions is split in two so that
      the newly added fields can go at the end.
      
      Patch by me, reviewed by Robert Haas, with additional input from Andres
      Freund and Tom Lane.
    cluster.c 51.96 KiB