← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/include/access/htup_details.h

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/include/access/htup_details.h
69
69
 *
70
70
 * We store five "virtual" fields Xmin, Cmin, Xmax, Cmax, and Xvac in three
71
71
 * physical fields.  Xmin and Xmax are always really stored, but Cmin, Cmax
72
 
 * and Xvac share a field.      This works because we know that Cmin and Cmax
 
72
 * and Xvac share a field.  This works because we know that Cmin and Cmax
73
73
 * are only interesting for the lifetime of the inserting and deleting
74
74
 * transaction respectively.  If a tuple is inserted and deleted in the same
75
75
 * transaction, we store a "combo" command id that can be mapped to the real
81
81
 * ie, an insert-in-progress or delete-in-progress tuple.)
82
82
 *
83
83
 * A word about t_ctid: whenever a new tuple is stored on disk, its t_ctid
84
 
 * is initialized with its own TID (location).  If the tuple is ever updated,
 
84
 * is initialized with its own TID (location).  If the tuple is ever updated,
85
85
 * its t_ctid is changed to point to the replacement version of the tuple.
86
86
 * Thus, a tuple is the latest version of its row iff XMAX is invalid or
87
87
 * t_ctid points to itself (in which case, if XMAX is valid, the tuple is
96
96
 * check fails, one may assume that there is no live descendant version.
97
97
 *
98
98
 * Following the fixed header fields, the nulls bitmap is stored (beginning
99
 
 * at t_bits).  The bitmap is *not* stored if t_infomask shows that there
 
99
 * at t_bits).  The bitmap is *not* stored if t_infomask shows that there
100
100
 * are no nulls in the tuple.  If an OID field is present (as indicated by
101
101
 * t_infomask), then it is stored just before the user data, which begins at
102
 
 * the offset shown by t_hoff.  Note that t_hoff must be a multiple of
 
102
 * the offset shown by t_hoff.  Note that t_hoff must be a multiple of
103
103
 * MAXALIGN.
104
104
 */
105
105
 
240
240
/*
241
241
 * HeapTupleHeader accessor macros
242
242
 *
243
 
 * Note: beware of multiple evaluations of "tup" argument.      But the Set
 
243
 * Note: beware of multiple evaluations of "tup" argument.  But the Set
244
244
 * macros evaluate their other argument only once.
245
245
 */
246
246
 
425
425
        (tup)->t_infomask2 = ((tup)->t_infomask2 & ~HEAP_NATTS_MASK) | (natts) \
426
426
)
427
427
 
 
428
#define HeapTupleHeaderHasExternal(tup) \
 
429
                (((tup)->t_infomask & HEAP_HASEXTERNAL) != 0)
 
430
 
428
431
 
429
432
/*
430
433
 * BITMAPLEN(NATTS) -
474
477
 * MinimalTuple is an alternative representation that is used for transient
475
478
 * tuples inside the executor, in places where transaction status information
476
479
 * is not required, the tuple rowtype is known, and shaving off a few bytes
477
 
 * is worthwhile because we need to store many tuples.  The representation
 
480
 * is worthwhile because we need to store many tuples.  The representation
478
481
 * is chosen so that tuple access routines can work with either full or
479
482
 * minimal tuples via a HeapTupleData pointer structure.  The access routines
480
483
 * see no difference, except that they must not access the transaction status
498
501
 * the MINIMAL_TUPLE_OFFSET distance.  t_len does not include that, however.
499
502
 *
500
503
 * MINIMAL_TUPLE_DATA_OFFSET is the offset to the first useful (non-pad) data
501
 
 * other than the length word.  tuplesort.c and tuplestore.c use this to avoid
 
504
 * other than the length word.  tuplesort.c and tuplestore.c use this to avoid
502
505
 * writing the padding to disk.
503
506
 */
504
507
#define MINIMAL_TUPLE_OFFSET \
644
647
 *              and set *isnull == true.  Otherwise, we set *isnull == false.
645
648
 *
646
649
 *              <tup> is the pointer to the heap tuple.  <attnum> is the attribute
647
 
 *              number of the column (field) caller wants.      <tupleDesc> is a
 
650
 *              number of the column (field) caller wants.  <tupleDesc> is a
648
651
 *              pointer to the structure describing the row and all its fields.
649
652
 * ----------------
650
653
 */
679
682
                                bool *isnull);
680
683
extern HeapTuple heap_copytuple(HeapTuple tuple);
681
684
extern void heap_copytuple_with_tuple(HeapTuple src, HeapTuple dest);
 
685
extern Datum heap_copy_tuple_as_datum(HeapTuple tuple, TupleDesc tupleDesc);
682
686
extern HeapTuple heap_form_tuple(TupleDesc tupleDescriptor,
683
687
                                Datum *values, bool *isnull);
684
688
extern HeapTuple heap_modify_tuple(HeapTuple tuple,