2005-04-28 23:47:18 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* htup.h
|
1997-09-07 07:04:48 +02:00
|
|
|
* POSTGRES heap tuple definitions.
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/access/htup.h
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef HTUP_H
|
1996-08-27 23:50:29 +02:00
|
|
|
#define HTUP_H
|
|
|
|
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "storage/itemptr.h"
|
1996-08-27 23:50:29 +02:00
|
|
|
|
2014-04-09 23:53:15 +02:00
|
|
|
/* typedefs and forward declarations for structs defined in htup_details.h */
|
2004-04-01 23:28:47 +02:00
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
typedef struct HeapTupleHeaderData HeapTupleHeaderData;
|
1996-08-27 23:50:29 +02:00
|
|
|
|
1998-11-27 20:33:35 +01:00
|
|
|
typedef HeapTupleHeaderData *HeapTupleHeader;
|
1996-08-27 23:50:29 +02:00
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
typedef struct MinimalTupleData MinimalTupleData;
|
2006-06-27 04:51:40 +02:00
|
|
|
|
|
|
|
typedef MinimalTupleData *MinimalTuple;
|
|
|
|
|
|
|
|
|
1998-11-27 20:33:35 +01:00
|
|
|
/*
|
2002-05-27 21:53:33 +02:00
|
|
|
* HeapTupleData is an in-memory data structure that points to a tuple.
|
2001-02-21 20:07:04 +01:00
|
|
|
*
|
2005-08-20 02:40:32 +02:00
|
|
|
* There are several ways in which this data structure is used:
|
|
|
|
*
|
|
|
|
* * Pointer to a tuple in a disk buffer: t_data points directly into the
|
|
|
|
* buffer (which the code had better be holding a pin on, but this is not
|
2005-11-20 20:49:08 +01:00
|
|
|
* reflected in HeapTupleData itself).
|
2005-08-20 02:40:32 +02:00
|
|
|
*
|
2005-11-20 20:49:08 +01:00
|
|
|
* * Pointer to nothing: t_data is NULL. This is used as a failure indication
|
|
|
|
* in some functions.
|
2005-08-20 02:40:32 +02:00
|
|
|
*
|
|
|
|
* * Part of a palloc'd tuple: the HeapTupleData itself and the tuple
|
|
|
|
* form a single palloc'd chunk. t_data points to the memory location
|
2005-11-20 20:49:08 +01:00
|
|
|
* immediately following the HeapTupleData struct (at offset HEAPTUPLESIZE).
|
|
|
|
* This is the output format of heap_form_tuple and related routines.
|
1998-11-27 20:33:35 +01:00
|
|
|
*
|
2005-08-20 02:40:32 +02:00
|
|
|
* * Separately allocated tuple: t_data points to a palloc'd chunk that
|
2014-05-06 18:12:18 +02:00
|
|
|
* is not adjacent to the HeapTupleData. (This case is deprecated since
|
2005-11-20 20:49:08 +01:00
|
|
|
* it's difficult to tell apart from case #1. It should be used only in
|
|
|
|
* limited contexts where the code knows that case #1 will never apply.)
|
1999-12-16 23:20:03 +01:00
|
|
|
*
|
2006-06-27 04:51:40 +02:00
|
|
|
* * Separately allocated minimal tuple: t_data points MINIMAL_TUPLE_OFFSET
|
2014-05-06 18:12:18 +02:00
|
|
|
* bytes before the start of a MinimalTuple. As with the previous case,
|
2006-06-27 04:51:40 +02:00
|
|
|
* this can't be told apart from case #1 by inspection; code setting up
|
|
|
|
* or destroying this representation has to know what it's doing.
|
|
|
|
*
|
2005-08-20 02:40:32 +02:00
|
|
|
* t_len should always be valid, except in the pointer-to-nothing case.
|
|
|
|
* t_self and t_tableOid should be valid if the HeapTupleData points to
|
|
|
|
* a disk buffer, or if it represents a copy of a tuple on disk. They
|
|
|
|
* should be explicitly set invalid in manufactured tuples.
|
1998-11-27 20:33:35 +01:00
|
|
|
*/
|
|
|
|
typedef struct HeapTupleData
|
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
uint32 t_len; /* length of *t_data */
|
|
|
|
ItemPointerData t_self; /* SelfItemPointer */
|
|
|
|
Oid t_tableOid; /* table the tuple came from */
|
|
|
|
HeapTupleHeader t_data; /* -> tuple header and data */
|
1998-11-27 20:33:35 +01:00
|
|
|
} HeapTupleData;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1998-11-27 20:33:35 +01:00
|
|
|
typedef HeapTupleData *HeapTuple;
|
|
|
|
|
1999-07-19 09:07:29 +02:00
|
|
|
#define HEAPTUPLESIZE MAXALIGN(sizeof(HeapTupleData))
|
1999-05-25 18:15:34 +02:00
|
|
|
|
1996-08-27 23:50:29 +02:00
|
|
|
/*
|
2004-04-01 23:28:47 +02:00
|
|
|
* Accessor macros to be used with HeapTuple pointers.
|
1996-08-27 23:50:29 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define HeapTupleIsValid(tuple) PointerIsValid(tuple)
|
1996-08-27 23:50:29 +02:00
|
|
|
|
2007-02-09 04:35:35 +01:00
|
|
|
/* HeapTupleHeader functions implemented in utils/time/combocid.c */
|
|
|
|
extern CommandId HeapTupleHeaderGetCmin(HeapTupleHeader tup);
|
|
|
|
extern CommandId HeapTupleHeaderGetCmax(HeapTupleHeader tup);
|
|
|
|
extern void HeapTupleHeaderAdjustCmax(HeapTupleHeader tup,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
CommandId *cmax, bool *iscombo);
|
|
|
|
|
|
|
|
/* Prototype for HeapTupleHeader accessors in heapam.c */
|
|
|
|
extern TransactionId HeapTupleGetUpdateXid(HeapTupleHeader tuple);
|
2007-02-09 04:35:35 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* HTUP_H */
|