|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* relcache.h
|
|
|
|
|
* Relation descriptor cache definitions.
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/include/utils/relcache.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef RELCACHE_H
|
|
|
|
|
#define RELCACHE_H
|
|
|
|
|
|
|
|
|
|
#include "access/tupdesc.h"
|
|
|
|
|
#include "nodes/bitmapset.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Name of relcache init file(s), used to speed up backend startup
|
|
|
|
|
*/
|
|
|
|
|
#define RELCACHE_INIT_FILENAME "pg_internal.init"
|
|
|
|
|
|
|
|
|
|
typedef struct RelationData *Relation;
|
|
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
|
* RelationPtr is used in the executor to support index scans
|
|
|
|
|
* where we have to keep track of several index relations in an
|
|
|
|
|
* array. -cim 9/10/89
|
|
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
typedef Relation *RelationPtr;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routines to open (lookup) and close a relcache entry
|
|
|
|
|
*/
|
|
|
|
|
extern Relation RelationIdGetRelation(Oid relationId);
|
|
|
|
|
extern void RelationClose(Relation relation);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routines to compute/retrieve additional cached information
|
|
|
|
|
*/
|
|
|
|
|
extern List *RelationGetFKeyList(Relation relation);
|
|
|
|
|
extern List *RelationGetIndexList(Relation relation);
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
9 years ago
|
|
|
extern List *RelationGetStatExtList(Relation relation);
|
|
|
|
|
extern Oid RelationGetPrimaryKeyIndex(Relation relation);
|
|
|
|
|
extern Oid RelationGetReplicaIndex(Relation relation);
|
|
|
|
|
extern List *RelationGetIndexExpressions(Relation relation);
|
|
|
|
|
extern List *RelationGetIndexPredicate(Relation relation);
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
12 years ago
|
|
|
|
|
|
|
|
typedef enum IndexAttrBitmapKind
|
|
|
|
|
{
|
|
|
|
|
INDEX_ATTR_BITMAP_ALL,
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
12 years ago
|
|
|
INDEX_ATTR_BITMAP_KEY,
|
|
|
|
|
INDEX_ATTR_BITMAP_PRIMARY_KEY,
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
12 years ago
|
|
|
INDEX_ATTR_BITMAP_IDENTITY_KEY
|
|
|
|
|
} IndexAttrBitmapKind;
|
|
|
|
|
|
|
|
|
|
extern Bitmapset *RelationGetIndexAttrBitmap(Relation relation,
|
|
|
|
|
IndexAttrBitmapKind keyAttrs);
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
12 years ago
|
|
|
|
|
|
|
|
extern void RelationGetExclusionInfo(Relation indexRelation,
|
|
|
|
|
Oid **operators,
|
|
|
|
|
Oid **procs,
|
|
|
|
|
uint16 **strategies);
|
|
|
|
|
|
|
|
|
|
extern void RelationSetIndexList(Relation relation,
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
7 years ago
|
|
|
List *indexIds);
|
|
|
|
|
|
|
|
|
|
extern void RelationInitIndexAccessInfo(Relation relation);
|
|
|
|
|
|
|
|
|
|
/* caller must include pg_publication.h */
|
|
|
|
|
struct PublicationActions;
|
|
|
|
|
extern struct PublicationActions *GetRelationPublicationActions(Relation relation);
|
|
|
|
|
|
Provide database object names as separate fields in error messages.
This patch addresses the problem that applications currently have to
extract object names from possibly-localized textual error messages,
if they want to know for example which index caused a UNIQUE_VIOLATION
failure. It adds new error message fields to the wire protocol, which
can carry the name of a table, table column, data type, or constraint
associated with the error. (Since the protocol spec has always instructed
clients to ignore unrecognized field types, this should not create any
compatibility problem.)
Support for providing these new fields has been added to just a limited set
of error reports (mainly, those in the "integrity constraint violation"
SQLSTATE class), but we will doubtless add them to more calls in future.
Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
additional hacking by Tom Lane.
13 years ago
|
|
|
/*
|
|
|
|
|
* Routines to support ereport() reports of relation-related errors
|
|
|
|
|
*/
|
|
|
|
|
extern int errtable(Relation rel);
|
|
|
|
|
extern int errtablecol(Relation rel, int attnum);
|
|
|
|
|
extern int errtablecolname(Relation rel, const char *colname);
|
|
|
|
|
extern int errtableconstraint(Relation rel, const char *conname);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routines for backend startup
|
|
|
|
|
*/
|
|
|
|
|
extern void RelationCacheInitialize(void);
|
|
|
|
|
extern void RelationCacheInitializePhase2(void);
|
|
|
|
|
extern void RelationCacheInitializePhase3(void);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routine to create a relcache entry for an about-to-be-created relation
|
|
|
|
|
*/
|
|
|
|
|
extern Relation RelationBuildLocalRelation(const char *relname,
|
|
|
|
|
Oid relnamespace,
|
|
|
|
|
TupleDesc tupDesc,
|
|
|
|
|
Oid relid,
|
|
|
|
|
Oid relfilenode,
|
|
|
|
|
Oid reltablespace,
|
|
|
|
|
bool shared_relation,
|
|
|
|
|
bool mapped_relation,
|
|
|
|
|
char relpersistence,
|
|
|
|
|
char relkind);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routine to manage assignment of new relfilenode to a relation
|
|
|
|
|
*/
|
|
|
|
|
extern void RelationSetNewRelfilenode(Relation relation, char persistence,
|
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
13 years ago
|
|
|
TransactionId freezeXid, MultiXactId minmulti);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routines for flushing/rebuilding relcache entries in various scenarios
|
|
|
|
|
*/
|
|
|
|
|
extern void RelationForgetRelation(Oid rid);
|
|
|
|
|
|
|
|
|
|
extern void RelationCacheInvalidateEntry(Oid relationId);
|
|
|
|
|
|
|
|
|
|
extern void RelationCacheInvalidate(void);
|
|
|
|
|
|
|
|
|
|
extern void RelationCloseSmgrByOid(Oid relationId);
|
|
|
|
|
|
|
|
|
|
extern void AtEOXact_RelationCache(bool isCommit);
|
|
|
|
|
extern void AtEOSubXact_RelationCache(bool isCommit, SubTransactionId mySubid,
|
|
|
|
|
SubTransactionId parentSubid);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Routines to help manage rebuilding of relcache init files
|
|
|
|
|
*/
|
Fix the logic for putting relations into the relcache init file.
Commit f3b5565dd4e59576be4c772da364704863e6a835 was a couple of bricks shy
of a load; specifically, it missed putting pg_trigger_tgrelid_tgname_index
into the relcache init file, because that index is not used by any
syscache. However, we have historically nailed that index into cache for
performance reasons. The upshot was that load_relcache_init_file always
decided that the init file was busted and silently ignored it, resulting
in a significant hit to backend startup speed.
To fix, reinstantiate RelationIdIsInInitFile() as a wrapper around
RelationSupportsSysCache(), which can know about additional relations
that should be in the init file despite being unknown to syscache.c.
Also install some guards against future mistakes of this type: make
write_relcache_init_file Assert that all nailed relations get written to
the init file, and make load_relcache_init_file emit a WARNING if it takes
the "wrong number of nailed relations" exit path. Now that we remove the
init files during postmaster startup, that case should never occur in the
field, even if we are starting a minor-version update that added or removed
rels from the nailed set. So the warning shouldn't ever be seen by end
users, but it will show up in the regression tests if somebody breaks this
logic.
Back-patch to all supported branches, like the previous commit.
11 years ago
|
|
|
extern bool RelationIdIsInInitFile(Oid relationId);
|
|
|
|
|
extern void RelationCacheInitFilePreInvalidate(void);
|
|
|
|
|
extern void RelationCacheInitFilePostInvalidate(void);
|
|
|
|
|
extern void RelationCacheInitFileRemove(void);
|
|
|
|
|
|
|
|
|
|
/* should be used only by relcache.c and catcache.c */
|
|
|
|
|
extern bool criticalRelcachesBuilt;
|
|
|
|
|
|
|
|
|
|
/* should be used only by relcache.c and postinit.c */
|
|
|
|
|
extern bool criticalSharedRelcachesBuilt;
|
|
|
|
|
|
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
9 years ago
|
|
|
#endif /* RELCACHE_H */
|
