Skip to content

G
Gpdb

Greenplum / Gpdb

通知 7
Star 1
Fork 0
G
Gpdb

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 2月, 2007 5 次提交
    • B
      Update workding for daylight savings time. · 63b7afbe
      由 Bruce Momjian 提交于
      63b7afbe
    • B
      Update timezone FAQ item: · a85a290d
      由 Bruce Momjian 提交于 
          <P>USA saving time changes are included in PostgreSQL release 8.0.[4+],
    and all later major releases, e.g. 8.1.  Canada and Western Australia
    changes are included in 8.0.[10+], 8.1.[6+], and all later major
    releases.  PostgreSQL releases prior to 8.0 use the operating system's
    timezone database for daylight saving information.</P>
      a85a290d
    • T
      Remove typmod checking from the recent security-related patches. It turns · a8c3f161
      由 Tom Lane 提交于 
      out that ExecEvalVar and friends don't necessarily have access to a tuple
descriptor with correct typmod: it definitely can contain -1, and possibly
might contain other values that are different from the Var's value.
Arguably this should be cleaned up someday, but it's not a simple change,
and in any case typmod discrepancies don't pose a security hazard.
Per reports from numerous people :-(

I'm not entirely sure whether the failure can occur in 8.0 --- the simple
test cases reported so far don't trigger it there.  But back-patch the
change all the way anyway.
      a8c3f161
    • B
      Split apart entries, one done now: · 869585cc
      由 Bruce Momjian 提交于 
      * -Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h
* Consider making NAMEDATALEN more configurable in future releases
      869585cc
    • T
      Fix typo in comment. · 28c3cd5c
      由 Tom Lane 提交于
      28c3cd5c
  3. 06 2月, 2007 10 次提交
  5. 05 2月, 2007 3 次提交
    • A
      Pass modern COPY syntax to backend, since copy (query) does not accept old... · 00ade1df
      由 Andrew Dunstan 提交于 
      Pass modern COPY syntax to backend, since copy (query) does not accept old syntax. Per complaint from Michael Fuhr.
      00ade1df
    • T
      Rename MaxTupleSize to MaxHeapTupleSize to clarify that it's not meant to · 23c4978e
      由 Tom Lane 提交于 
      describe the maximum size of index tuples (which is typically AM-dependent
anyway); and consequently remove the bogus deduction for "special space"
that was built into it.

Adjust TOAST_TUPLE_THRESHOLD and TOAST_MAX_CHUNK_SIZE to avoid wasting two
bytes per toast chunk, and to ensure that the calculation correctly tracks any
future changes in page header size.  The computation had been inaccurate in a
way that didn't cause any harm except space wastage, but future changes could
have broken it more drastically.

Fix the calculation of BTMaxItemSize, which was formerly computed as 1 byte
more than it could safely be.  This didn't cause any harm in practice because
it's only compared against maxalign'd lengths, but future changes in the size
of page headers or btree special space could have exposed the problem.

initdb forced because of change in TOAST_MAX_CHUNK_SIZE, which alters the
storage of toast tables.
      23c4978e
    • T
      Don't MAXALIGN in the checks to decide whether a tuple is over TOAST's · a2e092e1
      由 Tom Lane 提交于 
      threshold for tuple length.  On 4-byte-MAXALIGN machines, the toast code
creates tuples that have t_len exactly TOAST_TUPLE_THRESHOLD ... but this
number is not itself maxaligned, so if heap_insert maxaligns t_len before
comparing to TOAST_TUPLE_THRESHOLD, it'll uselessly recurse back to
tuptoaster.c, wasting cycles.  (It turns out that this does not happen on
8-byte-MAXALIGN machines, because for them the outer MAXALIGN in the
TOAST_MAX_CHUNK_SIZE macro reduces TOAST_MAX_CHUNK_SIZE so that toast tuples
will be less than TOAST_TUPLE_THRESHOLD in size.  That MAXALIGN is really
incorrect, but we can't remove it now, see below.)  There isn't any particular
value in maxaligning before comparing to the thresholds, so just don't do
that, which saves a small number of cycles in itself.

These numbers should be rejiggered to minimize wasted space on toast-relation
pages, but we can't do that in the back branches because changing
TOAST_MAX_CHUNK_SIZE would force an initdb (by changing the contents of toast
tables).  We can move the toast decision thresholds a bit, though, which is
what this patch effectively does.

Thanks to Pavan Deolasee for discovering the unintended recursion.

Back-patch into 8.2, but not further, pending more testing.  (HEAD is about
to get a further patch modifying the thresholds, so it won't help much
for testing this form of the patch.)
      a2e092e1
  7. 04 2月, 2007 10 次提交
  9. 03 2月, 2007 8 次提交
  11. 02 2月, 2007 4 次提交