2019-04-04 10:56:03 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* sync.h
|
|
|
|
* File synchronization management code.
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2019-04-04 10:56:03 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* src/include/storage/sync.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef SYNC_H
|
|
|
|
#define SYNC_H
|
|
|
|
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
#include "storage/relfilelocator.h"
|
2019-04-04 10:56:03 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Type of sync request. These are used to manage the set of pending
|
|
|
|
* requests to call a sync handler's sync or unlink functions at the next
|
|
|
|
* checkpoint.
|
|
|
|
*/
|
|
|
|
typedef enum SyncRequestType
|
|
|
|
{
|
|
|
|
SYNC_REQUEST, /* schedule a call of sync function */
|
|
|
|
SYNC_UNLINK_REQUEST, /* schedule a call of unlink function */
|
|
|
|
SYNC_FORGET_REQUEST, /* forget all calls for a tag */
|
|
|
|
SYNC_FILTER_REQUEST /* forget all calls satisfying match fn */
|
|
|
|
} SyncRequestType;
|
|
|
|
|
|
|
|
/*
|
2019-04-10 02:49:49 +02:00
|
|
|
* Which set of functions to use to handle a given request. The values of
|
|
|
|
* the enumerators must match the indexes of the function table in sync.c.
|
2019-04-04 10:56:03 +02:00
|
|
|
*/
|
|
|
|
typedef enum SyncRequestHandler
|
|
|
|
{
|
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
|
|
|
SYNC_HANDLER_MD = 0,
|
|
|
|
SYNC_HANDLER_CLOG,
|
|
|
|
SYNC_HANDLER_COMMIT_TS,
|
|
|
|
SYNC_HANDLER_MULTIXACT_OFFSET,
|
|
|
|
SYNC_HANDLER_MULTIXACT_MEMBER,
|
|
|
|
SYNC_HANDLER_NONE
|
2019-04-04 10:56:03 +02:00
|
|
|
} SyncRequestHandler;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A tag identifying a file. Currently it has the members required for md.c's
|
|
|
|
* usage, but sync.c has no knowledge of the internal structure, and it is
|
|
|
|
* liable to change as required by future handlers.
|
|
|
|
*/
|
|
|
|
typedef struct FileTag
|
|
|
|
{
|
2019-06-08 04:46:38 +02:00
|
|
|
int16 handler; /* SyncRequestHandler value, saving space */
|
2019-04-04 10:56:03 +02:00
|
|
|
int16 forknum; /* ForkNumber, saving space */
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
RelFileLocator rlocator;
|
2019-04-04 10:56:03 +02:00
|
|
|
uint32 segno;
|
|
|
|
} FileTag;
|
|
|
|
|
|
|
|
extern void InitSync(void);
|
|
|
|
extern void SyncPreCheckpoint(void);
|
|
|
|
extern void SyncPostCheckpoint(void);
|
|
|
|
extern void ProcessSyncRequests(void);
|
|
|
|
extern void RememberSyncRequest(const FileTag *ftag, SyncRequestType type);
|
|
|
|
extern bool RegisterSyncRequest(const FileTag *ftag, SyncRequestType type,
|
|
|
|
bool retryOnError);
|
|
|
|
|
|
|
|
#endif /* SYNC_H */
|