2004-07-01 02:52:04 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* subtrans.c
|
2004-08-24 01:22:45 +02:00
|
|
|
* PostgreSQL subtransaction-log manager
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
2017-03-17 14:46:58 +01:00
|
|
|
* The pg_subtrans manager is a pg_xact-like manager that stores the parent
|
2004-07-01 02:52:04 +02:00
|
|
|
* transaction Id for each transaction. It is a fundamental part of the
|
|
|
|
* nested transactions implementation. A main transaction has a parent
|
|
|
|
* of InvalidTransactionId, and each subtransaction has its immediate parent.
|
|
|
|
* The tree can easily be walked from child to parent, but not in the
|
|
|
|
* opposite direction.
|
|
|
|
*
|
2017-05-31 19:34:41 +02:00
|
|
|
* This code is based on xact.c, but the robustness requirements
|
2017-03-17 14:46:58 +01:00
|
|
|
* are completely different from pg_xact, because we only need to remember
|
2004-08-24 01:22:45 +02:00
|
|
|
* pg_subtrans information for currently-open transactions. Thus, there is
|
|
|
|
* no need to preserve data over a crash and restart.
|
|
|
|
*
|
|
|
|
* There are no XLOG interactions since we do not care about preserving
|
|
|
|
* data across crashes. During database startup, we simply force the
|
|
|
|
* currently-active page of SUBTRANS to zeroes.
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2004-07-01 02:52:04 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/access/transam/subtrans.c
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/slru.h"
|
|
|
|
#include "access/subtrans.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/transam.h"
|
2008-08-01 15:16:09 +02:00
|
|
|
#include "pg_trace.h"
|
2008-03-26 19:48:59 +01:00
|
|
|
#include "utils/snapmgr.h"
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Defines for SubTrans page sizes. A page is the same BLCKSZ as is used
|
|
|
|
* everywhere else in Postgres.
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
|
|
|
* Note: because TransactionIds are 32 bits and wrap around at 0xFFFFFFFF,
|
|
|
|
* SubTrans page numbering also wraps around at
|
|
|
|
* 0xFFFFFFFF/SUBTRANS_XACTS_PER_PAGE, and segment numbering at
|
2015-04-14 17:12:18 +02:00
|
|
|
* 0xFFFFFFFF/SUBTRANS_XACTS_PER_PAGE/SLRU_PAGES_PER_SEGMENT. We need take no
|
2004-07-01 02:52:04 +02:00
|
|
|
* explicit notice of that fact in this module, except when comparing segment
|
2016-02-19 09:31:12 +01:00
|
|
|
* and page numbers in TruncateSUBTRANS (see SubTransPagePrecedes) and zeroing
|
|
|
|
* them in StartupSUBTRANS.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* We need four bytes per xact */
|
|
|
|
#define SUBTRANS_XACTS_PER_PAGE (BLCKSZ / sizeof(TransactionId))
|
|
|
|
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
/*
|
|
|
|
* Although we return an int64 the actual value can't currently exceed
|
|
|
|
* 0xFFFFFFFF/SUBTRANS_XACTS_PER_PAGE.
|
|
|
|
*/
|
|
|
|
static inline int64
|
|
|
|
TransactionIdToPage(TransactionId xid)
|
|
|
|
{
|
|
|
|
return xid / (int64) SUBTRANS_XACTS_PER_PAGE;
|
|
|
|
}
|
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
#define TransactionIdToEntry(xid) ((xid) % (TransactionId) SUBTRANS_XACTS_PER_PAGE)
|
|
|
|
|
|
|
|
|
2004-08-24 01:22:45 +02:00
|
|
|
/*
|
|
|
|
* Link to shared-memory data structures for SUBTRANS control
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
static SlruCtlData SubTransCtlData;
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-08-24 01:22:45 +02:00
|
|
|
#define SubTransCtl (&SubTransCtlData)
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
static int ZeroSUBTRANSPage(int64 pageno);
|
|
|
|
static bool SubTransPagePrecedes(int64 page1, int64 page2);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Record the parent of a subtransaction in the subtrans log.
|
|
|
|
*/
|
|
|
|
void
|
2017-04-27 14:41:22 +02:00
|
|
|
SubTransSetParent(TransactionId xid, TransactionId parent)
|
2004-07-01 02:52:04 +02:00
|
|
|
{
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
int64 pageno = TransactionIdToPage(xid);
|
2004-07-01 02:52:04 +02:00
|
|
|
int entryno = TransactionIdToEntry(xid);
|
2004-08-24 01:22:45 +02:00
|
|
|
int slotno;
|
2004-07-01 02:52:04 +02:00
|
|
|
TransactionId *ptr;
|
|
|
|
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
Assert(TransactionIdIsValid(parent));
|
2017-04-27 14:41:22 +02:00
|
|
|
Assert(TransactionIdFollows(xid, parent));
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockAcquire(SubtransSLRULock, LW_EXCLUSIVE);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2007-08-02 00:45:09 +02:00
|
|
|
slotno = SimpleLruReadPage(SubTransCtl, pageno, true, xid);
|
2004-08-24 01:22:45 +02:00
|
|
|
ptr = (TransactionId *) SubTransCtl->shared->page_buffer[slotno];
|
2004-07-01 02:52:04 +02:00
|
|
|
ptr += entryno;
|
|
|
|
|
2017-04-27 14:41:22 +02:00
|
|
|
/*
|
|
|
|
* It's possible we'll try to set the parent xid multiple times but we
|
|
|
|
* shouldn't ever be changing the xid from one valid xid to another valid
|
|
|
|
* xid, which would corrupt the data structure.
|
|
|
|
*/
|
|
|
|
if (*ptr != parent)
|
|
|
|
{
|
|
|
|
Assert(*ptr == InvalidTransactionId);
|
|
|
|
*ptr = parent;
|
|
|
|
SubTransCtl->shared->page_dirty[slotno] = true;
|
|
|
|
}
|
2004-07-01 02:52:04 +02:00
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockRelease(SubtransSLRULock);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Interrogate the parent of a transaction in the subtrans log.
|
|
|
|
*/
|
|
|
|
TransactionId
|
|
|
|
SubTransGetParent(TransactionId xid)
|
|
|
|
{
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
int64 pageno = TransactionIdToPage(xid);
|
2004-07-01 02:52:04 +02:00
|
|
|
int entryno = TransactionIdToEntry(xid);
|
2004-08-24 01:22:45 +02:00
|
|
|
int slotno;
|
2004-07-01 02:52:04 +02:00
|
|
|
TransactionId *ptr;
|
|
|
|
TransactionId parent;
|
|
|
|
|
2004-08-22 04:41:58 +02:00
|
|
|
/* Can't ask about stuff that might not be around anymore */
|
2004-09-16 20:35:23 +02:00
|
|
|
Assert(TransactionIdFollowsOrEquals(xid, TransactionXmin));
|
2004-08-22 04:41:58 +02:00
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
/* Bootstrap and frozen XIDs have no parent */
|
|
|
|
if (!TransactionIdIsNormal(xid))
|
|
|
|
return InvalidTransactionId;
|
|
|
|
|
2005-12-06 19:10:06 +01:00
|
|
|
/* lock is acquired by SimpleLruReadPage_ReadOnly */
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2005-12-06 19:10:06 +01:00
|
|
|
slotno = SimpleLruReadPage_ReadOnly(SubTransCtl, pageno, xid);
|
2004-08-24 01:22:45 +02:00
|
|
|
ptr = (TransactionId *) SubTransCtl->shared->page_buffer[slotno];
|
2004-07-01 02:52:04 +02:00
|
|
|
ptr += entryno;
|
|
|
|
|
|
|
|
parent = *ptr;
|
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockRelease(SubtransSLRULock);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
return parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SubTransGetTopmostTransaction
|
|
|
|
*
|
|
|
|
* Returns the topmost transaction of the given transaction id.
|
2004-08-22 04:41:58 +02:00
|
|
|
*
|
2004-09-16 20:35:23 +02:00
|
|
|
* Because we cannot look back further than TransactionXmin, it is possible
|
2004-08-22 04:41:58 +02:00
|
|
|
* that this function will lie and return an intermediate subtransaction ID
|
|
|
|
* instead of the true topmost parent ID. This is OK, because in practice
|
|
|
|
* we only care about detecting whether the topmost parent is still running
|
|
|
|
* or is part of a current snapshot's list of still-running transactions.
|
2004-09-16 20:35:23 +02:00
|
|
|
* Therefore, any XID before TransactionXmin is as good as any other.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
TransactionId
|
|
|
|
SubTransGetTopmostTransaction(TransactionId xid)
|
|
|
|
{
|
|
|
|
TransactionId parentXid = xid,
|
|
|
|
previousXid = xid;
|
|
|
|
|
2004-08-22 04:41:58 +02:00
|
|
|
/* Can't ask about stuff that might not be around anymore */
|
2004-09-16 20:35:23 +02:00
|
|
|
Assert(TransactionIdFollowsOrEquals(xid, TransactionXmin));
|
2004-08-22 04:41:58 +02:00
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
while (TransactionIdIsValid(parentXid))
|
|
|
|
{
|
|
|
|
previousXid = parentXid;
|
2004-09-16 20:35:23 +02:00
|
|
|
if (TransactionIdPrecedes(parentXid, TransactionXmin))
|
2004-08-22 04:41:58 +02:00
|
|
|
break;
|
2004-07-01 02:52:04 +02:00
|
|
|
parentXid = SubTransGetParent(parentXid);
|
2017-04-27 14:41:22 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* By convention the parent xid gets allocated first, so should always
|
|
|
|
* precede the child xid. Anything else points to a corrupted data
|
|
|
|
* structure that could lead to an infinite loop, so exit.
|
|
|
|
*/
|
|
|
|
if (!TransactionIdPrecedes(parentXid, previousXid))
|
|
|
|
elog(ERROR, "pg_subtrans contains invalid entry: xid %u points to parent xid %u",
|
|
|
|
previousXid, parentXid);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Assert(TransactionIdIsValid(previousXid));
|
|
|
|
|
|
|
|
return previousXid;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Initialization of shared memory for SUBTRANS
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
2005-08-21 01:26:37 +02:00
|
|
|
Size
|
2004-07-01 02:52:04 +02:00
|
|
|
SUBTRANSShmemSize(void)
|
|
|
|
{
|
2007-08-02 00:45:09 +02:00
|
|
|
return SimpleLruShmemSize(NUM_SUBTRANS_BUFFERS, 0);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
SUBTRANSShmemInit(void)
|
|
|
|
{
|
|
|
|
SubTransCtl->PagePrecedes = SubTransPagePrecedes;
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
SimpleLruInit(SubTransCtl, "Subtrans", NUM_SUBTRANS_BUFFERS, 0,
|
|
|
|
SubtransSLRULock, "pg_subtrans",
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
LWTRANCHE_SUBTRANS_BUFFER, SYNC_HANDLER_NONE,
|
|
|
|
false);
|
2021-01-16 21:21:35 +01:00
|
|
|
SlruPagePrecedesUnitTests(SubTransCtl, SUBTRANS_XACTS_PER_PAGE);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This func must be called ONCE on system install. It creates
|
2004-08-24 01:22:45 +02:00
|
|
|
* the initial SUBTRANS segment. (The SUBTRANS directory is assumed to
|
|
|
|
* have been created by the initdb shell script, and SUBTRANSShmemInit
|
|
|
|
* must have been called already.)
|
|
|
|
*
|
|
|
|
* Note: it's not really necessary to create the initial segment now,
|
|
|
|
* since slru.c would create it on first write anyway. But we may as well
|
|
|
|
* do it to be sure the directory is set up correctly.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
BootStrapSUBTRANS(void)
|
|
|
|
{
|
|
|
|
int slotno;
|
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockAcquire(SubtransSLRULock, LW_EXCLUSIVE);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2004-08-24 01:22:45 +02:00
|
|
|
/* Create and zero the first page of the subtrans log */
|
|
|
|
slotno = ZeroSUBTRANSPage(0);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
/* Make sure it's written out */
|
2010-12-30 16:09:17 +01:00
|
|
|
SimpleLruWritePage(SubTransCtl, slotno);
|
2005-11-05 22:19:47 +01:00
|
|
|
Assert(!SubTransCtl->shared->page_dirty[slotno]);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockRelease(SubtransSLRULock);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Initialize (or reinitialize) a page of SUBTRANS to zeroes.
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
|
|
|
* The page is not actually written, just set up in shared memory.
|
|
|
|
* The slot number of the new page is returned.
|
|
|
|
*
|
|
|
|
* Control lock must be held at entry, and will be held at exit.
|
|
|
|
*/
|
|
|
|
static int
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
ZeroSUBTRANSPage(int64 pageno)
|
2004-07-01 02:52:04 +02:00
|
|
|
{
|
2004-08-24 01:22:45 +02:00
|
|
|
return SimpleLruZeroPage(SubTransCtl, pageno);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This must be called ONCE during postmaster or standalone-backend startup,
|
2020-08-11 20:25:23 +02:00
|
|
|
* after StartupXLOG has initialized ShmemVariableCache->nextXid.
|
2005-06-18 00:32:51 +02:00
|
|
|
*
|
2020-08-11 20:25:23 +02:00
|
|
|
* oldestActiveXID is the oldest XID of any prepared transaction, or nextXid
|
2005-06-18 00:32:51 +02:00
|
|
|
* if there are none.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
void
|
2005-06-18 00:32:51 +02:00
|
|
|
StartupSUBTRANS(TransactionId oldestActiveXID)
|
2004-07-01 02:52:04 +02:00
|
|
|
{
|
2020-08-11 20:25:23 +02:00
|
|
|
FullTransactionId nextXid;
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
int64 startPage;
|
|
|
|
int64 endPage;
|
2004-08-24 01:22:45 +02:00
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Since we don't expect pg_subtrans to be valid across crashes, we
|
2005-06-18 00:32:51 +02:00
|
|
|
* initialize the currently-active page(s) to zeroes during startup.
|
2004-08-24 01:22:45 +02:00
|
|
|
* Whenever we advance into a new page, ExtendSUBTRANS will likewise zero
|
|
|
|
* the new page without regard to whatever was previously on disk.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockAcquire(SubtransSLRULock, LW_EXCLUSIVE);
|
2004-08-24 01:22:45 +02:00
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
startPage = TransactionIdToPage(oldestActiveXID);
|
2020-08-11 20:25:23 +02:00
|
|
|
nextXid = ShmemVariableCache->nextXid;
|
|
|
|
endPage = TransactionIdToPage(XidFromFullTransactionId(nextXid));
|
2005-06-18 00:32:51 +02:00
|
|
|
|
|
|
|
while (startPage != endPage)
|
|
|
|
{
|
|
|
|
(void) ZeroSUBTRANSPage(startPage);
|
|
|
|
startPage++;
|
2016-02-19 09:31:12 +01:00
|
|
|
/* must account for wraparound */
|
|
|
|
if (startPage > TransactionIdToPage(MaxTransactionId))
|
|
|
|
startPage = 0;
|
2005-06-18 00:32:51 +02:00
|
|
|
}
|
2004-08-24 01:22:45 +02:00
|
|
|
(void) ZeroSUBTRANSPage(startPage);
|
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockRelease(SubtransSLRULock);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Perform a checkpoint --- either during shutdown, or on-the-fly
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
CheckPointSUBTRANS(void)
|
|
|
|
{
|
2004-08-24 01:22:45 +02:00
|
|
|
/*
|
Defer flushing of SLRU files.
Previously, we called fsync() after writing out individual pg_xact,
pg_multixact and pg_commit_ts pages due to cache pressure, leading to
regular I/O stalls in user backends and recovery. Collapse requests for
the same file into a single system call as part of the next checkpoint,
as we already did for relation files, using the infrastructure developed
by commit 3eb77eba. This can cause a significant improvement to
recovery performance, especially when it's otherwise CPU-bound.
Hoist ProcessSyncRequests() up into CheckPointGuts() to make it clearer
that it applies to all the SLRU mini-buffer-pools as well as the main
buffer pool. Rearrange things so that data collected in CheckpointStats
includes SLRU activity.
Also remove the Shutdown{CLOG,CommitTS,SUBTRANS,MultiXact}() functions,
because they were redundant after the shutdown checkpoint that
immediately precedes them. (I'm not sure if they were ever needed, but
they aren't now.)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (parts)
Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com>
Discussion: https://postgr.es/m/CA+hUKGLJ=84YT+NvhkEEDAuUtVHMfQ9i-N7k_o50JmQ6Rpj_OQ@mail.gmail.com
2020-09-25 08:49:43 +02:00
|
|
|
* Write dirty SUBTRANS pages to disk
|
2004-08-24 01:22:45 +02:00
|
|
|
*
|
|
|
|
* This is not actually necessary from a correctness point of view. We do
|
|
|
|
* it merely to improve the odds that writing of dirty pages is done by
|
|
|
|
* the checkpoint process and not by backends.
|
|
|
|
*/
|
2008-08-01 15:16:09 +02:00
|
|
|
TRACE_POSTGRESQL_SUBTRANS_CHECKPOINT_START(true);
|
Defer flushing of SLRU files.
Previously, we called fsync() after writing out individual pg_xact,
pg_multixact and pg_commit_ts pages due to cache pressure, leading to
regular I/O stalls in user backends and recovery. Collapse requests for
the same file into a single system call as part of the next checkpoint,
as we already did for relation files, using the infrastructure developed
by commit 3eb77eba. This can cause a significant improvement to
recovery performance, especially when it's otherwise CPU-bound.
Hoist ProcessSyncRequests() up into CheckPointGuts() to make it clearer
that it applies to all the SLRU mini-buffer-pools as well as the main
buffer pool. Rearrange things so that data collected in CheckpointStats
includes SLRU activity.
Also remove the Shutdown{CLOG,CommitTS,SUBTRANS,MultiXact}() functions,
because they were redundant after the shutdown checkpoint that
immediately precedes them. (I'm not sure if they were ever needed, but
they aren't now.)
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (parts)
Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com>
Discussion: https://postgr.es/m/CA+hUKGLJ=84YT+NvhkEEDAuUtVHMfQ9i-N7k_o50JmQ6Rpj_OQ@mail.gmail.com
2020-09-25 08:49:43 +02:00
|
|
|
SimpleLruWriteAll(SubTransCtl, true);
|
2008-08-01 15:16:09 +02:00
|
|
|
TRACE_POSTGRESQL_SUBTRANS_CHECKPOINT_DONE(true);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Make sure that SUBTRANS has room for a newly-allocated XID.
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
|
|
|
* NB: this is called while holding XidGenLock. We want it to be very fast
|
|
|
|
* most of the time; even when it's not so fast, no actual I/O need happen
|
2004-08-24 01:22:45 +02:00
|
|
|
* unless we're forced to write out a dirty subtrans page to make room
|
2004-07-01 02:52:04 +02:00
|
|
|
* in shared memory.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ExtendSUBTRANS(TransactionId newestXact)
|
|
|
|
{
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
int64 pageno;
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* No work except at first XID of a page. But beware: just after
|
|
|
|
* wraparound, the first XID of page zero is FirstNormalTransactionId.
|
|
|
|
*/
|
|
|
|
if (TransactionIdToEntry(newestXact) != 0 &&
|
|
|
|
!TransactionIdEquals(newestXact, FirstNormalTransactionId))
|
|
|
|
return;
|
|
|
|
|
|
|
|
pageno = TransactionIdToPage(newestXact);
|
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockAcquire(SubtransSLRULock, LW_EXCLUSIVE);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2004-08-24 01:22:45 +02:00
|
|
|
/* Zero the page */
|
|
|
|
ZeroSUBTRANSPage(pageno);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than
being shmem lookup keys, so not a lot of thought went into them.
As of v13, though, we're exposing them in the pg_stat_slru view and
the pg_stat_reset_slru function, so it seems advisable to take a bit
more care. Rename them to names based on the associated on-disk
storage directories (which fortunately we *did* think about, to some
extent; since those are also visible to DBAs, consistency seems like
a good thing). Also rename the associated LWLocks, since those names
are likewise user-exposed now as wait event names.
For the most part I only touched symbols used in the respective modules'
SimpleLruInit() calls, not the names of other related objects. This
renaming could have been taken further, and maybe someday we will do so.
But for now it seems undesirable to change the names of any globally
visible functions or structs, so some inconsistency is unavoidable.
(But I *did* terminate "oldserxid" with prejudice, as I found that
name both unreadable and not descriptive of the SLRU's contents.)
Table 27.12 needs re-alphabetization now, but I'll leave that till
after the other LWLock renamings I have in mind.
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
|
|
|
LWLockRelease(SubtransSLRULock);
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-08-24 01:22:45 +02:00
|
|
|
* Remove all SUBTRANS segments before the one holding the passed transaction ID
|
2004-07-01 02:52:04 +02:00
|
|
|
*
|
2020-08-15 19:15:53 +02:00
|
|
|
* oldestXact is the oldest TransactionXmin of any running transaction. This
|
|
|
|
* is called only during checkpoint.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
TruncateSUBTRANS(TransactionId oldestXact)
|
|
|
|
{
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
int64 cutoffPage;
|
2004-07-01 02:52:04 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The cutoff point is the start of the segment containing oldestXact. We
|
2015-07-23 00:29:59 +02:00
|
|
|
* pass the *page* containing oldestXact to SimpleLruTruncate. We step
|
|
|
|
* back one transaction to avoid passing a cutoff page that hasn't been
|
|
|
|
* created yet in the rare case that oldestXact would be the first item on
|
|
|
|
* a page and oldestXact == next XID. In that case, if we didn't subtract
|
|
|
|
* one, we'd trigger SimpleLruTruncate's wraparound detection.
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
2015-07-23 00:29:59 +02:00
|
|
|
TransactionIdRetreat(oldestXact);
|
2004-07-01 02:52:04 +02:00
|
|
|
cutoffPage = TransactionIdToPage(oldestXact);
|
2004-08-24 01:22:45 +02:00
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
SimpleLruTruncate(SubTransCtl, cutoffPage);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2021-01-16 21:21:35 +01:00
|
|
|
* Decide whether a SUBTRANS page number is "older" for truncation purposes.
|
|
|
|
* Analogous to CLOGPagePrecedes().
|
2004-07-01 02:52:04 +02:00
|
|
|
*/
|
|
|
|
static bool
|
Index SLRUs by 64-bit integers rather than by 32-bit integers
We've had repeated bugs in the area of handling SLRU wraparound in the past,
some of which have caused data loss. Switching to an indexing system for SLRUs
that does not wrap around should allow us to get rid of a whole bunch
of problems and improve the overall reliability of the system.
This particular patch however only changes the indexing and doesn't address
the wraparound per se. This is going to be done in the following patches.
Author: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev
Author: Nikita Glukhov, Pavel Borisov, Yura Sokolov
Reviewed-by: Jacob Champion, Heikki Linnakangas, Alexander Korotkov
Reviewed-by: Japin Li, Pavel Borisov, Tom Lane, Peter Eisentraut, Andres Freund
Reviewed-by: Andrey Borodin, Dilip Kumar, Aleksander Alekseev
Discussion: https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Discussion: https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
2023-11-29 00:39:55 +01:00
|
|
|
SubTransPagePrecedes(int64 page1, int64 page2)
|
2004-07-01 02:52:04 +02:00
|
|
|
{
|
|
|
|
TransactionId xid1;
|
|
|
|
TransactionId xid2;
|
|
|
|
|
|
|
|
xid1 = ((TransactionId) page1) * SUBTRANS_XACTS_PER_PAGE;
|
2021-01-16 21:21:35 +01:00
|
|
|
xid1 += FirstNormalTransactionId + 1;
|
2004-07-01 02:52:04 +02:00
|
|
|
xid2 = ((TransactionId) page2) * SUBTRANS_XACTS_PER_PAGE;
|
2021-01-16 21:21:35 +01:00
|
|
|
xid2 += FirstNormalTransactionId + 1;
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2021-01-16 21:21:35 +01:00
|
|
|
return (TransactionIdPrecedes(xid1, xid2) &&
|
|
|
|
TransactionIdPrecedes(xid1, xid2 + SUBTRANS_XACTS_PER_PAGE - 1));
|
2004-07-01 02:52:04 +02:00
|
|
|
}
|