mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-04 20:23:24 +02:00
b0a55e4329
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
112 lines
4.4 KiB
C
112 lines
4.4 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* smgr.h
|
|
* storage manager switch public interface declarations.
|
|
*
|
|
*
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/storage/smgr.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef SMGR_H
|
|
#define SMGR_H
|
|
|
|
#include "lib/ilist.h"
|
|
#include "storage/block.h"
|
|
#include "storage/relfilelocator.h"
|
|
|
|
/*
|
|
* smgr.c maintains a table of SMgrRelation objects, which are essentially
|
|
* cached file handles. An SMgrRelation is created (if not already present)
|
|
* by smgropen(), and destroyed by smgrclose(). Note that neither of these
|
|
* operations imply I/O, they just create or destroy a hashtable entry.
|
|
* (But smgrclose() may release associated resources, such as OS-level file
|
|
* descriptors.)
|
|
*
|
|
* An SMgrRelation may have an "owner", which is just a pointer to it from
|
|
* somewhere else; smgr.c will clear this pointer if the SMgrRelation is
|
|
* closed. We use this to avoid dangling pointers from relcache to smgr
|
|
* without having to make the smgr explicitly aware of relcache. There
|
|
* can't be more than one "owner" pointer per SMgrRelation, but that's
|
|
* all we need.
|
|
*
|
|
* SMgrRelations that do not have an "owner" are considered to be transient,
|
|
* and are deleted at end of transaction.
|
|
*/
|
|
typedef struct SMgrRelationData
|
|
{
|
|
/* rlocator is the hashtable lookup key, so it must be first! */
|
|
RelFileLocatorBackend smgr_rlocator; /* relation physical identifier */
|
|
|
|
/* pointer to owning pointer, or NULL if none */
|
|
struct SMgrRelationData **smgr_owner;
|
|
|
|
/*
|
|
* The following fields are reset to InvalidBlockNumber upon a cache flush
|
|
* event, and hold the last known size for each fork. This information is
|
|
* currently only reliable during recovery, since there is no cache
|
|
* invalidation for fork extension.
|
|
*/
|
|
BlockNumber smgr_targblock; /* current insertion target block */
|
|
BlockNumber smgr_cached_nblocks[MAX_FORKNUM + 1]; /* last known size */
|
|
|
|
/* additional public fields may someday exist here */
|
|
|
|
/*
|
|
* Fields below here are intended to be private to smgr.c and its
|
|
* submodules. Do not touch them from elsewhere.
|
|
*/
|
|
int smgr_which; /* storage manager selector */
|
|
|
|
/*
|
|
* for md.c; per-fork arrays of the number of open segments
|
|
* (md_num_open_segs) and the segments themselves (md_seg_fds).
|
|
*/
|
|
int md_num_open_segs[MAX_FORKNUM + 1];
|
|
struct _MdfdVec *md_seg_fds[MAX_FORKNUM + 1];
|
|
|
|
/* if unowned, list link in list of all unowned SMgrRelations */
|
|
dlist_node node;
|
|
} SMgrRelationData;
|
|
|
|
typedef SMgrRelationData *SMgrRelation;
|
|
|
|
#define SmgrIsTemp(smgr) \
|
|
RelFileLocatorBackendIsTemp((smgr)->smgr_rlocator)
|
|
|
|
extern void smgrinit(void);
|
|
extern SMgrRelation smgropen(RelFileLocator rlocator, BackendId backend);
|
|
extern bool smgrexists(SMgrRelation reln, ForkNumber forknum);
|
|
extern void smgrsetowner(SMgrRelation *owner, SMgrRelation reln);
|
|
extern void smgrclearowner(SMgrRelation *owner, SMgrRelation reln);
|
|
extern void smgrclose(SMgrRelation reln);
|
|
extern void smgrcloseall(void);
|
|
extern void smgrcloserellocator(RelFileLocatorBackend rlocator);
|
|
extern void smgrrelease(SMgrRelation reln);
|
|
extern void smgrreleaseall(void);
|
|
extern void smgrcreate(SMgrRelation reln, ForkNumber forknum, bool isRedo);
|
|
extern void smgrdosyncall(SMgrRelation *rels, int nrels);
|
|
extern void smgrdounlinkall(SMgrRelation *rels, int nrels, bool isRedo);
|
|
extern void smgrextend(SMgrRelation reln, ForkNumber forknum,
|
|
BlockNumber blocknum, char *buffer, bool skipFsync);
|
|
extern bool smgrprefetch(SMgrRelation reln, ForkNumber forknum,
|
|
BlockNumber blocknum);
|
|
extern void smgrread(SMgrRelation reln, ForkNumber forknum,
|
|
BlockNumber blocknum, char *buffer);
|
|
extern void smgrwrite(SMgrRelation reln, ForkNumber forknum,
|
|
BlockNumber blocknum, char *buffer, bool skipFsync);
|
|
extern void smgrwriteback(SMgrRelation reln, ForkNumber forknum,
|
|
BlockNumber blocknum, BlockNumber nblocks);
|
|
extern BlockNumber smgrnblocks(SMgrRelation reln, ForkNumber forknum);
|
|
extern BlockNumber smgrnblocks_cached(SMgrRelation reln, ForkNumber forknum);
|
|
extern void smgrtruncate(SMgrRelation reln, ForkNumber *forknum,
|
|
int nforks, BlockNumber *nblocks);
|
|
extern void smgrimmedsync(SMgrRelation reln, ForkNumber forknum);
|
|
extern void AtEOXact_SMgr(void);
|
|
extern bool ProcessBarrierSmgrRelease(void);
|
|
|
|
#endif /* SMGR_H */
|