Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the function of mdread function in PostgreSQL". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the function of mdread in PostgreSQL"?

The mdread function of PostgreSQL storage management is the function responsible for reading in magnetic disk storage management.

I. data structure

Smgrsw

The pointer structure of f_smgr function defines the API function between independent storage management module and smgr.c.

Md is the abbreviation of magnetic disk.

In addition to md, the previous PG also supported two storage methods: Sony WORM optical disk jukebox and persistent main memory.

But only magnetic disk is left behind, and the rest has been abandoned and no longer supported.

The name "magnetic disk" itself is misleading. In fact, md can support any type of device that the operating system provides a standard file system.

/ * * This struct of function pointers defines the API between smgr.c and * any individual storage manager module. Note that smgr subfunctions are * generally expected to report problems via elog (ERROR). An exception is * that smgr_unlink should use elog (WARNING), rather than erroring out, * because we normally unlink relations during post-commit/abort cleanup, * and so it's too late to raise an error. Also, various conditions that * would normally be errors should be allowed during bootstrap and/or WAL * recovery-see comments in md.c for details. * the function pointer structure defines the API function between the independent storage management module and smgr.c. * Note that the SMG subfunction usually reports errors through elog (ERROR). * one exception is that smgr_unlink should use elog (WARNING) instead of throwing errors, * because unlinke relationships are unlinked only during transaction commit / rollback cleanup, * so it's too late to throw errors. * at the same time, during bootstrap and / or WAL recovery, various possible errors should also be allowed-see the comments in md.c for details. * / typedef struct f_smgr {void (* smgr_init) (void); / * may be NULL * / void (* smgr_shutdown) (void); / * may be NULL * / void (* smgr_close) (SMgrRelation reln, ForkNumber forknum); void (* smgr_create) (SMgrRelation reln, ForkNumber forknum, bool isRedo) Bool (* smgr_exists) (SMgrRelation reln, ForkNumber forknum); void (* smgr_unlink) (RelFileNodeBackend rnode, ForkNumber forknum, bool isRedo); void (* smgr_extend) (SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum, char * buffer, bool skipFsync) Void (* smgr_prefetch) (SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum); void (* smgr_read) (SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum, char * buffer) Void (* smgr_write) (SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum, char * buffer, bool skipFsync); void (* smgr_writeback) (SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum, BlockNumber nblocks); BlockNumber (* smgr_nblocks) (SMgrRelation reln, ForkNumber forknum) Void (* smgr_truncate) (SMgrRelation reln, ForkNumber forknum, BlockNumber nblocks); void (* smgr_immedsync) (SMgrRelation reln, ForkNumber forknum); void (* smgr_pre_ckpt) (void); / * may be NULL * / void (* smgr_sync) (void) / * may be NULL * / void (* smgr_post_ckpt) (void); / * may be NULL * /} the abbreviation of magnetic disk. In addition to md, the previous PG also supports Sony WORM optical disk jukebox and persistent main memory, but only magnetic disk is left behind, and the rest has been discarded and no longer supported. The name of "magnetic disk" itself is also misleading. In fact, md can support any type of device that the operating system provides a standard file system. * / static const f_smgr smgrsw [] = {/ * magnetic disk * / {.smgr _ init = mdinit .smgr _ shutdown = NULL, .smgr _ close = mdclose, .smgr _ create = mdcreate, .smgr _ exists = mdexists, .smgr _ unlink = mdunlink, .smgr _ extend = mdextend, .smgr _ prefetch = mdprefetch, .smgr _ read = mdread, .smgr _ write = mdwrite, .smgr _ writeback = mdwriteback, .smgr _ nblocks = mdnblocks, .smgr _ truncate = mdtruncate .smgr _ immedsync = mdimmedsync, .smgr _ pre_ckpt = mdpreckpt, .smgr _ sync = mdsync, .smgr _ post_ckpt = mdpostckpt}}

MdfdVec

Magnetic disk Storage Management tracks open file descriptors in its own descriptor pool.

This is done because it is easy to support relationships that exceed the upper limit of os file size (usually 2GB).

To achieve this, we split the relationship into multiple "segment" files that are smaller than the OS file size limit.

The segment size is set by the RELSEG_SIZE configuration parameter defined in pg_config.h.

/ * * The magnetic disk storage manager keeps track of open file * descriptors in its own descriptor pool. This is done to make it * easier to support relations that are larger than the operating * system's file size limit (often 2GBytes). In order to do that, * we break relations up into "segment" files that are each shorter than * the OS file size limit. The segment size is set by the RELSEG_SIZE * configuration constant in pg_config.h. * magnetic disk Storage Management tracks open file descriptors in its own descriptor pool. * this is done because it is easy to support relationships that exceed the upper limit of os file size (usually 2GB). * to achieve this, we split the relationship into multiple "segment" files that are smaller than the OS file size limit. * the segment size is set by the RELSEG_SIZE configuration parameter defined in pg_config.h. * * On disk, a relation must consist of consecutively numbered segment * files in the pattern *-- Zero or more full segments of exactly RELSEG_SIZE blocks each *-- Exactly one partial segment of size 0

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.