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

xlog.c

Blame
    • Heikki Linnakangas's avatar
      3f0e808c
      Introduce the concept of relation forks. An smgr relation can now consist · 3f0e808c
      Heikki Linnakangas authored
      of multiple forks, and each fork can be created and grown separately.
      
      The bulk of this patch is about changing the smgr API to include an extra
      ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
      smgrdounlink no longer implicitly call smgrclose, because other forks might
      still exist after unlinking one. The callers of those functions have been
      modified to call smgrclose instead.
      
      This patch in itself doesn't have any user-visible effect, but provides the
      infrastructure needed for upcoming patches. The additional forks envisioned
      are a rewritten FSM implementation that doesn't rely on a fixed-size shared
      memory block, and a visibility map to allow skipping portions of a table in
      VACUUM that have no dead tuples.
      3f0e808c
      History
      Introduce the concept of relation forks. An smgr relation can now consist
      Heikki Linnakangas authored
      of multiple forks, and each fork can be created and grown separately.
      
      The bulk of this patch is about changing the smgr API to include an extra
      ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
      smgrdounlink no longer implicitly call smgrclose, because other forks might
      still exist after unlinking one. The callers of those functions have been
      modified to call smgrclose instead.
      
      This patch in itself doesn't have any user-visible effect, but provides the
      infrastructure needed for upcoming patches. The additional forks envisioned
      are a rewritten FSM implementation that doesn't rely on a fixed-size shared
      memory block, and a visibility map to allow skipping portions of a table in
      VACUUM that have no dead tuples.