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

Project.pm

Blame
    • Tom Lane's avatar
      cd004067
      Replace time_t with pg_time_t (same values, but always int64) in on-disk · cd004067
      Tom Lane authored
      data structures and backend internal APIs.  This solves problems we've seen
      recently with inconsistent layout of pg_control between machines that have
      32-bit time_t and those that have already migrated to 64-bit time_t.  Also,
      we can get out from under the problem that Windows' Unix-API emulation is not
      consistent about the width of time_t.
      
      There are a few remaining places where local time_t variables are used to hold
      the current or recent result of time(NULL).  I didn't bother changing these
      since they do not affect any cross-module APIs and surely all platforms will
      have 64-bit time_t before overflow becomes an actual risk.  time_t should
      be avoided for anything visible to extension modules, however.
      cd004067
      History
      Replace time_t with pg_time_t (same values, but always int64) in on-disk
      Tom Lane authored
      data structures and backend internal APIs.  This solves problems we've seen
      recently with inconsistent layout of pg_control between machines that have
      32-bit time_t and those that have already migrated to 64-bit time_t.  Also,
      we can get out from under the problem that Windows' Unix-API emulation is not
      consistent about the width of time_t.
      
      There are a few remaining places where local time_t variables are used to hold
      the current or recent result of time(NULL).  I didn't bother changing these
      since they do not affect any cross-module APIs and surely all platforms will
      have 64-bit time_t before overflow becomes an actual risk.  time_t should
      be avoided for anything visible to extension modules, however.