1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* lmgr.h
|
1996-08-28 03:59:28 +02:00
|
|
|
* POSTGRES lock manager definitions.
|
|
|
|
*
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/storage/lmgr.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef LMGR_H
|
|
|
|
#define LMGR_H
|
|
|
|
|
2007-06-19 22:13:22 +02:00
|
|
|
#include "lib/stringinfo.h"
|
2008-05-12 02:00:54 +02:00
|
|
|
#include "storage/itemptr.h"
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "storage/lock.h"
|
|
|
|
#include "utils/rel.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2005-04-30 21:03:33 +02:00
|
|
|
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
/* XactLockTableWait operations */
|
|
|
|
typedef enum XLTW_Oper
|
|
|
|
{
|
|
|
|
XLTW_None,
|
|
|
|
XLTW_Update,
|
|
|
|
XLTW_Delete,
|
|
|
|
XLTW_Lock,
|
|
|
|
XLTW_LockUpdated,
|
|
|
|
XLTW_InsertIndex,
|
|
|
|
XLTW_InsertIndexUnique,
|
|
|
|
XLTW_FetchUpdated,
|
|
|
|
XLTW_RecheckExclusionConstr
|
|
|
|
} XLTW_Oper;
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
extern void RelationInitLockInfo(Relation relation);
|
|
|
|
|
2000-12-22 01:51:54 +01:00
|
|
|
/* Lock a relation */
|
2006-07-31 22:09:10 +02:00
|
|
|
extern void LockRelationOid(Oid relid, LOCKMODE lockmode);
|
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
|
|
|
extern void LockRelationId(LockRelId *relid, LOCKMODE lockmode);
|
2006-07-31 22:09:10 +02:00
|
|
|
extern bool ConditionalLockRelationOid(Oid relid, LOCKMODE lockmode);
|
|
|
|
extern void UnlockRelationId(LockRelId *relid, LOCKMODE lockmode);
|
2006-08-18 18:09:13 +02:00
|
|
|
extern void UnlockRelationOid(Oid relid, LOCKMODE lockmode);
|
2006-07-31 22:09:10 +02:00
|
|
|
|
1998-12-15 13:47:01 +01:00
|
|
|
extern void LockRelation(Relation relation, LOCKMODE lockmode);
|
2001-06-22 02:04:59 +02:00
|
|
|
extern bool ConditionalLockRelation(Relation relation, LOCKMODE lockmode);
|
1998-12-15 13:47:01 +01:00
|
|
|
extern void UnlockRelation(Relation relation, LOCKMODE lockmode);
|
2018-10-01 18:43:21 +02:00
|
|
|
extern bool CheckRelationLockedByMe(Relation relation, LOCKMODE lockmode,
|
|
|
|
bool orstronger);
|
Fix performance problems with autovacuum truncation in busy workloads.
In situations where there are over 8MB of empty pages at the end of
a table, the truncation work for trailing empty pages takes longer
than deadlock_timeout, and there is frequent access to the table by
processes other than autovacuum, there was a problem with the
autovacuum worker process being canceled by the deadlock checking
code. The truncation work done by autovacuum up that point was
lost, and the attempt tried again by a later autovacuum worker. The
attempts could continue indefinitely without making progress,
consuming resources and blocking other processes for up to
deadlock_timeout each time.
This patch has the autovacuum worker checking whether it is
blocking any other thread at 20ms intervals. If such a condition
develops, the autovacuum worker will persist the work it has done
so far, release its lock on the table, and sleep in 50ms intervals
for up to 5 seconds, hoping to be able to re-acquire the lock and
try again. If it is unable to get the lock in that time, it moves
on and a worker will try to continue later from the point this one
left off.
While this patch doesn't change the rules about when and what to
truncate, it does cause the truncation to occur sooner, with less
blocking, and with the consumption of fewer resources when there is
contention for the table's lock.
The only user-visible change other than improved performance is
that the table size during truncation may change incrementally
instead of just once.
This problem exists in all supported versions but is infrequently
reported, although some reports of performance problems when
autovacuum runs might be caused by this. Initial commit is just the
master branch, but this should probably be backpatched once the
build farm and general developer usage confirm that there are no
surprising effects.
Jan Wieck
2012-12-11 21:33:08 +01:00
|
|
|
extern bool LockHasWaitersRelation(Relation relation, LOCKMODE lockmode);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2006-07-31 22:09:10 +02:00
|
|
|
extern void LockRelationIdForSession(LockRelId *relid, LOCKMODE lockmode);
|
|
|
|
extern void UnlockRelationIdForSession(LockRelId *relid, LOCKMODE lockmode);
|
2000-12-22 01:51:54 +01:00
|
|
|
|
2005-04-30 00:28:24 +02:00
|
|
|
/* Lock a relation for extension */
|
|
|
|
extern void LockRelationForExtension(Relation relation, LOCKMODE lockmode);
|
|
|
|
extern void UnlockRelationForExtension(Relation relation, LOCKMODE lockmode);
|
2016-04-08 08:04:46 +02:00
|
|
|
extern bool ConditionalLockRelationForExtension(Relation relation,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
extern int RelationExtensionLockWaiterCount(Relation relation);
|
2005-04-30 00:28:24 +02:00
|
|
|
|
2020-08-15 19:15:53 +02:00
|
|
|
/* Lock to recompute pg_database.datfrozenxid in the current database */
|
|
|
|
extern void LockDatabaseFrozenIds(LOCKMODE lockmode);
|
|
|
|
|
2005-04-30 00:28:24 +02:00
|
|
|
/* Lock a page (currently only used within indexes) */
|
1998-12-15 13:47:01 +01:00
|
|
|
extern void LockPage(Relation relation, BlockNumber blkno, LOCKMODE lockmode);
|
2003-09-05 00:06:27 +02:00
|
|
|
extern bool ConditionalLockPage(Relation relation, BlockNumber blkno, LOCKMODE lockmode);
|
1998-12-15 13:47:01 +01:00
|
|
|
extern void UnlockPage(Relation relation, BlockNumber blkno, LOCKMODE lockmode);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2005-04-30 21:03:33 +02:00
|
|
|
/* Lock a tuple (see heap_lock_tuple before assuming you understand this) */
|
|
|
|
extern void LockTuple(Relation relation, ItemPointer tid, LOCKMODE lockmode);
|
2005-08-01 22:31:16 +02:00
|
|
|
extern bool ConditionalLockTuple(Relation relation, ItemPointer tid,
|
|
|
|
LOCKMODE lockmode);
|
2005-04-30 21:03:33 +02:00
|
|
|
extern void UnlockTuple(Relation relation, ItemPointer tid, LOCKMODE lockmode);
|
|
|
|
|
2000-12-22 01:51:54 +01:00
|
|
|
/* Lock an XID (used to wait for a transaction to finish) */
|
1998-12-15 13:47:01 +01:00
|
|
|
extern void XactLockTableInsert(TransactionId xid);
|
2004-09-16 18:58:44 +02:00
|
|
|
extern void XactLockTableDelete(TransactionId xid);
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
extern void XactLockTableWait(TransactionId xid, Relation rel,
|
|
|
|
ItemPointer ctid, XLTW_Oper oper);
|
2005-08-01 22:31:16 +02:00
|
|
|
extern bool ConditionalXactLockTableWait(TransactionId xid);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2013-09-27 16:46:33 +02:00
|
|
|
/* Lock VXIDs, specified by conflicting locktags */
|
Report progress of CREATE INDEX operations
This uses the progress reporting infrastructure added by c16dc1aca5e0,
adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY.
There are two pieces to this: one is index-AM-agnostic, and the other is
AM-specific. The latter is fairly elaborate for btrees, including
reportage for parallel index builds and the separate phases that btree
index creation uses; other index AMs, which are much simpler in their
building procedures, have simplistic reporting only, but that seems
sufficient, at least for non-concurrent builds.
The index-AM-agnostic part is fairly complete, providing insight into
the CONCURRENTLY wait phases as well as block-based progress during the
index validation table scan. (The index validation index scan requires
patching each AM, which has not been included here.)
Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada
Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
|
|
|
extern void WaitForLockers(LOCKTAG heaplocktag, LOCKMODE lockmode, bool progress);
|
|
|
|
extern void WaitForLockersMultiple(List *locktags, LOCKMODE lockmode, bool progress);
|
2013-09-27 16:46:33 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/* Lock an XID for tuple insertion (used to wait for an insertion to finish) */
|
|
|
|
extern uint32 SpeculativeInsertionLockAcquire(TransactionId xid);
|
|
|
|
extern void SpeculativeInsertionLockRelease(TransactionId xid);
|
|
|
|
extern void SpeculativeInsertionWait(TransactionId xid, uint32 token);
|
|
|
|
|
2005-04-30 21:03:33 +02:00
|
|
|
/* Lock a general object (other than a relation) of the current database */
|
|
|
|
extern void LockDatabaseObject(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
extern void UnlockDatabaseObject(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
|
|
|
|
/* Lock a shared-across-databases object (other than a relation) */
|
|
|
|
extern void LockSharedObject(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
extern void UnlockSharedObject(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
|
2008-11-07 19:25:07 +01:00
|
|
|
extern void LockSharedObjectForSession(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
extern void UnlockSharedObjectForSession(Oid classid, Oid objid, uint16 objsubid,
|
|
|
|
LOCKMODE lockmode);
|
|
|
|
|
2007-06-19 22:13:22 +02:00
|
|
|
/* Describe a locktag for error messages */
|
|
|
|
extern void DescribeLockTag(StringInfo buf, const LOCKTAG *tag);
|
|
|
|
|
2016-03-10 18:44:09 +01:00
|
|
|
extern const char *GetLockNameFromTagType(uint16 locktag_type);
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
#endif /* LMGR_H */
|