Postgresql 体系架构 - 物理结构
在 PostgreSOL的体系架构中，最重要的组成部分是数据的存储结构，而数据的存储结构分为以下两种。
逻辑存储结构:数据库内部组织和管理数据的方式
物理存储结构:操作系统中组织和管理数据的方式。
PostgreSOL的体系架构如图所示
- 物理结构
1.1. 相关概念
1.1.1. OID
OID（对象标识符）在整个数据库中唯一地标识一个数据库对象，这个数据库对象可以是数据库、表、索引、视图、元组、类型等，保存在无符号四字节的整形变量中。所有数据库对象各自对应一个OID。
对象标识符（oid）在PostgreSQL内部用作各种系统表的主键。类型oid表示对象标识符。oid还有几个别名类型，每个都命名regsomething。
oid类型目前实现为无符号四字节整数。因此，它并不大足以在大型数据库甚至大型单个表中提供数据库范围内的惟一性。oid类型本身除了比较之外几乎没有什么操作。但是，它可以被强制转换为整数，并且然后使用标准整数运算符进行操作。除了专门的输入和输出例程外，OID别名类型没有自己的操作。
这些例程能够接受并显示系统对象的符号名称，而不是原始的类型oid将使用的数值。别名类型允许简化对OID值的查找对象。例如，要检查与表mytable相关的pg_attribute行
SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;
更胜于使用:
SELECT * FROM pg_attribute WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');
虽然一个表的文件节点通常和它的 OID相匹配； 但实际上也没必要如此，如ALTER TABLE, TRUNCATE, REINDEX, CLUSTER等操作，可以改变文件节点而同时保留相匹配，但实际上并不必 TRUNCATE、REINDEX、CLUSTER以及某些形式 OID。避免假设该文件节点和表OID相同。同样，对于某些系统目录，包括pg_class本身，pg_class.Relfilenode包含零。这些目录的实际文件编号为存储在较低级别的数据结构中，可以使用pg_relation_filen ode()函数获取。
1.1.2 relfilenode
在PostgreSQL中，relfilenode是一个对象（比如表、索引、序列等）在文件系统上的物理存储文件的编号。
在表或者索引超过 1GB 之后，它就被划分成1G大小的段。 第一个段的文件名和文件节点相同；随后的段被命名为 filenode.1、filenode.2等等。这样的安排避免了在某些有文件大 小限制的平台上的问题（实际上，1GB只是默认的段尺寸。段尺寸可以在编译PostgreSQL时 使用配置选项--with-segsize进行调整）。原则上，空闲空间映射和可见性映射分支也可以要求多个段，但实际上这很少发生。 如果一个表的列中可能存储相当大的项，那么该表就会有个与之相关联的TOAST表， 它用于 存储无法保留在在表行中的域值的线外存储。
该文件有1G的大小限制，超过1G或生成新的文件（文件名后边加数字编号）；
relfilenode标识对象物理位置的数字标号，会随数据存放的变化位置变化而变化；
函数pg_relation_filenode() 可以获得对象的relfilenode；
postgres=# select pg_relation_filenode('test');
postgres=# truncate table test;
postgres=# select pg_relation_filenode('test');
truncate之后，t2表的relfilenode从16388变为了16391.
通过pg_relation_filenode()可以将oid转化为relfilenode，
通过pg_filenode_relation可以将relfilenode转化为oid.
使用pg_relation_filenode()永远会得到正确的结果，从pg_class系统表中查询则可能会得到错误的结果。
获得表的oid信息：
postgres=#select oid from pg_class where relname='test';
postgres=#select 'test'::regclass::oid;
先查看数据库的
postgres=# select oid,datname from pg_database;
查找物理文件所在位置：
postgres=#select oid,relfilenode from pg_class where relname='test';
postgres=# select pg_relation_filepath('test');
- 1.3. Relation
关系代表非数据库本身的数据库对象，包括表、视图、索引和toast等，不包括数据库本身。
- 1.4 MVCC
Multi-Version-Concurrency-Control是一种并发控制机制，用于允许一些transactions读取和写入相同的行，而不会因一个进程导致其他进程停顿。在PostgreSQL 中，MVCC是通过在tuples被修改时创建副本(versions)来实现的;在可以看到旧版本终止的事务之后，需要删除那些旧版本。数据库引擎根据不同的事务隔离级别， 通过查询事务快照和事务提交日志来完成元组的可见性检查。
- 1.5. LSN
LSN（Log Sequence Number，日志序列号）是 PostgreSQL 中用于标识数据库操作日志位置的 64 位标识符，是确保数据一致性和完整性的关键。LSN 通常表示为 X/Y 的形式。 其中 X 和 Y 为十六进制数。前 32 位 (X) 表示日志文件的编号，后 32 位 (Y) 表示日志文 件中的偏移量。例如，16/B374D848。每次数据库发生写操作时，PostgreSQL 会在 WAL 日志 中记录这些操作，并分配一个新的 LSN，以便在系统故障后进行恢复。
使用 pg_waldump 打印
[postgres@pgserver01 pg_wal]$ pg_waldump 000000010000000000000001
获取当前的 LSN 值
postgres=# select pg_current_wal_lsn();
从 LSN 计算出 WAL 文件名（注意：timeline 是根据当前实例生成的，不同实例的 timeline 字段计算结果可能不同）
postgres=# select pg_walfile_name('0/17FB7B0');
2. Page结构
据库文件在Linux平台被划分为默认8K固定长度的page进行管理，通过启动参数 BLCKSIZE可以预设page的大小。如果page设低了，相同数据量的文件需要分裂成更多的 page，IO次数和索引分裂次数都会增加，性能会降低较多；如果page设高了，page内部的数据检索效率会降低，性能一样会降低不少，一般来说8K和16K对于数据库系统来说是最优解。
上图为一个page的结构，主要由5个部分组成：
Page Header：为页头，主要存储LSN，page中空闲空间的开始offset和结束offset等。下面再展开讲。
ItemId data：是page中表记录的索引条目。一个索引条目4个字节，由两部分组成：此记录在page中的offset和记录长度length。
Free space：是此page中剩余可用的空间，不算标记为delete后的空间；是指完全没有被使用的空间，也相当于page中没有被分配的空间。
Item：就是指表实际存储的记录。
Special space: 存储索引访问方法(AM: Access Method)信息，不同的索引访问方法，内容不一样。但如果是表的page，那么这里是空的，没有任何信息。
页头部分其实是这个 page 的一些元数据信息，由 PageHeaderData 结构体表示，主要有如下内容：
pd_lsn：xlog（WAL） 在当前 page 的最后一次修改的日志记录
pd_checksum：文件页对应的校验和，保护文件页内容
pd_flags：page 的一些状态信息，取值有如下几种
PD_HAS_FREE_LINES：是否还有未使用的 linp 指针
PD_PAGE_FULL：页面已满，剩余的空间无法容纳新的 Tuple
PD_ALL_VISIBLE：page 所有的 tuple 都是可见的
PD_VALID_FLAG_BITS：全部有效的 pd_flags 标记位
pd_lower：该 page 内空闲空间的起始位置
pd_upper：该 page 内空闲空间的结束位置
pd_special：存储一些特定的信息，比如 BTree 索引会用到
pd_pagesize_version：存储页面大小和版本信息
pd_prune_xid：page 中可删除的最旧的事务 ID
pd_linp：即前面注释中标注的 linp 1 linp 2 linp 3 ... Linp n，是一个数组，用来标识 page 内一条数据的位置偏移，使用结构体 ItemIdData 表示。
2.1. FSM（Free Space Map）
FSM 结构来管理数据页中的空闲空间，FSM是存在以_fsm为后缀的文件中的，每个表都 有一个对应的fsm 文件。fsm 文件的初始大小为24KB，在表创建以后的第一次VACCUM 操作中被创建，而且在接下来的每次VACCUM操作中被更新。
空闲空间映射表的目的为：当有一个元组需要储存时，快速定位到有足够（能够容纳这个元组）空闲空间的表文件块；或者能够快速判断是否存在有足够空间的表文件块，从而决定是直接插入还是新增表文件块。
2.2. 可见性映射(VM)
VM主要的作用为，在我们对表中的行做了update, delete 后，这一行的 tuple 并不会马上被清理掉，pg会通过vacuum 操作将这些dead tuple 清理， vm文件的主要作用是显示占用tuple ， 扫描的时候会跳过这些tuple。
2.3. TOAST 策略
TOAST（The Oversized-Attribute Storage Technique）是PostgreSQL中用于处理大型数据类型的一种技术。PG 页面大小默认时8k，当数据类型的大小超过存储系统的限制时，TOAST技术会将数据拆分成多个块并单独存储，以避免数据存储空间的浪费。
TOAST技术主要应用于以下几种数据类型：
大型二进制数据（如图像、音频、视频等）
大型文本数据（如长文本、JSON等）
大型数字数据（如大数、精度较高的浮点数等）
通过使用TOAST技术，PostgreSQL能够有效地处理大型数据类型，提高数据的存储效率和查询性能。同时，TOAST还能够自动处理数据的压缩和解压缩，使得数据在存储和检索时更加高效。
3. PG存储目录结构
通常数据库使用的配置和数据文件在数据库初始化后都被一起存储在的数据目录里， 用$PGDATA来引用, 常见位置是/var/ lib/pgsql/data。
在postgresql中，表空间的概念并不同于其他关系型数据库，这里一个Tablespace对应的都是一个目录。如下图就是PG的物理结构
3.1. PGDATA文件结构
| 项 | 描述 |
| PG_VERSION | 一个包含PostgreSQL主版本号的文件 |
| base | 包含每个数据库对应的子目录的子目录,该目录包含数据库用户所创建的各个数据库,同时也包括 postgrestemplate0 和template1 的pg default tablespace |
| current_logfiles | 记录当前被日志收集器写入的日志文件的文件 |
| global | 包含集簇范围的表的子目录，比 如pg_database, pg_tablespace |
| pg_commit_ts | 包含事务提交时间戳数据的子目录 |
| pg_dynshmem | 包含被动态共享内存子系统所使用的文件的子目录 |
| pg_logical | 包含用于逻辑复制的状态数据的子目录 |
| pg_multixact | 包含多事务（multi-transaction）状态数据的子目录（用于共享的行锁） |
| pg_notify | 包含LISTEN/NOTIFY状态数据的子目录 |
| pg_replslot | 包含复制槽数据的子目录 |
| pg_serial | 包含已提交的可序列化事务信息的子目录 |
| pg_snapshots | 包含导出的快照的子目录 |
| pg_stat | 包含用于统计子系统的永久文件的子目录 |
| pg_stat_tmp | 包含用于统计信息子系统的临时文件的子目 录 |
| pg_subtrans | 包含子事务状态数据的子目录 |
| pg_tblspc | 包含指向表空间的符号链接的子目录 |
| pg_twophase | 包含用于预备事务状态文件的子目录 |
| pg_wal | 包含 WAL （预写日志）文件的子目录 |
| pg_xact | 包含事务提交状态数据的子目录 |
| postgresql.auto.conf | 一个用于存储由ALTER SYSTEM 设置的配置参 数的文件 |
| postmaster.opts | 一个记录服务器最后一次启动时使用的命令 行参数的文件 |
| postmaster.pid | 一个锁文件，记录着当前的 postmaster进程ID（PID）、集簇数据目录路径、postmaster启动时间戳、端口号、Unix |
3.1.1 Base
base 目录存储用户创建的数据库文件，及隶属于用户数据库的所有关系，比如表、索引等。
postgres=# select datname ,oid from pg_database;
主数据文件存储隶属于对应数据库下的数据库关系文件，包括数据、索引等，用户最重要的业务数据便是存储在主数据文件中。
SELECT pg_relation_filepath('test');
用户通过SQL查询到的单行数据记录对应单个元组（tuple），因为MVCC机制的原因，元组可能是无法查询到旧版本数据，也可能是活跃的新版本数据，旧版本数据会在未来的某个时刻被清理。当查询没有命中索引触发顺序扫描时，数据库引擎顺序扫描page的行指针读取到元组，反之如果命中 B 树索引，引擎会通过索引文件的元组，通过索引键的 TID 值读取到元组。
3.1.2 WAL机制
Write-Ahead-Logging：日志先行机制。数据变更优先写入日志文件，事务失败则变更记录被忽略，事务成功再选择合适时机写入数据文件，数据的刷盘速度慢于日志刷盘速度。当数据库系统崩溃后，引擎会从上一次成功的checkpoint点开始依次重放wal记录，如果LSN>pd_lsn则重放wal记录，反之跳过，确保数据记录恢复到崩溃前的状态。
（1）LSN
当每个新记录被写入时，WAL记录被追加到WAL日志中。 插入位置由日志序列号 （LSN）描述，该日志序列号是日志中的字节偏移量， 随每个新记录单调递增。LSN 值作为数据类型 pg_lsn返回。 值可以进行比较以计算分离它们的WAL数据量，因此 它们用于衡量复制和恢复的进度。
##切日志的方式
postgres=# select pg_switch_wal();
（2）wal segment
wal 段文件存储着数据库行记录明细，每一条记录明细都是服务于数据库恢复操作的，确保前后数据一致。首先针对数据的任意一次修改操作均被记录在wal段文件中，包括insert、update 和delete，其次系统的一些管理行为也会被记录在wal段文件中，例如事务提交和vacuum等行为。
（3）.history
.history文件内容包括原.history文件，当前时间线切换记录和切换原因，作用于数据库的时间点恢复行为。当数据库引擎从多个时间线的备份中恢复时，数据库从.history文件中找到从pg_control的start_timeline到指定的recovery_target_timeline间的所有wal段文件进行恢复。 为了解决这个问题，PostgreSQL引入了时间线的概念。每当归档文件恢复完成后，创建一个新的时间线用来区别新生成的WAL记录。
（4）archive_status
archive_status是wal段文件的备份目录，包括.ready和.done文件。超出wal_keep_segments数 目限制的wal日志会在archive_status目录内被打标，归档操作完成后被进一步移除。
.ready 是同名wal段文件在archive_status 目录内的标记文件，代表该wal段文件可被归档。 如何归档？ .done 是同名wal段文件在archive_status 目录内的标记文件，代表该wal段文件已被归档，可以被清理。
wal_keep_size: 用于指定 pg_wal 目录下要保留的wal日志的最少尺寸 pg_wal 目录中的 WAL 段文件数量取决于min_wal_size、max_wal_size以及在之前的检查点周 期中产生的 WAL 数量。
3.1.3 日志文件
PostgreSQL日志文件的类型，分为以下几种：
（1）pg_xact 事务日志
事务提交日志，记录元数据；默认开启。内容一般不能直接读。目录在$PGDATA/pg_xact，pg_xact是事务提交日志（Commit Log）的存储目录，事务提交日志默认256KB，文件名形如NNNN，系统初始化后从0000开 始递增至FFFF。 PG 10 及之后的高版本改目录名为pg_xact，10之前目录名称是pg_clog。 下图是pg_xact目录下的clog文件，027E前的文件因为事务已被冻结，所以被vacuum清理完毕。
（2）pg_log 运行日志
记录服务器与数据库的运行日志，告警日志，错误日志，定位慢查询SQL，数据库的启动关闭信息，发生checkpoint过于频繁等的告警信息等。该日志有.csv格式和.log。建议使用.csv格式，因为它一般会按大小和时间自动切割。
默认没有开启，开启后会自动生成。查看postgresql.conf文件的配置可以看到相关的参数设置。pg_log是可以被清理删除，压缩打包或者转移，同时并不影响DB的正常运行。当我们有遇到DB无法启动或者更改参数没有生效时，第一个想到的就是查看这个日志。
##参数文件配置
logging_collector = on
log_directory = ‘pg_log’
log_filename = ‘postgresql-%a.log’ log_truncate_on_rotation = on
##修改在线日志格式
postgres=# alter system set log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log’; 注：需要重启数据库
pg_ctl stop pg_ctl start
postgres=# select name from pg_settings where name in (‘log_filename’，‘log_directory’,‘logging_collector’);
记录日志格式设置 log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
它可以包含以下参数，每个参数都表示不同的含义:
%a : 当前会话的应用名称。。
%u : 当前会话的用户名。
%d : 当前数据库的名称。
%r : 当前会话的远程主机地址。
%p : 当前会话的进程 ID。
%t: 当前时间戳。
%m: 当前会话的日志消息类型。
%s: 当前会话的会话 ID。
%i : 当前会话的事务 ID。
%e : 当前会话的错误代码。
%c: 当前会话的命令标识符
（3）pg_xlog 预写日志（重做日志）
pg_xlog 这个日志是记录的Postgresql的WAL信息，默认存储在目录$PGDATA/pg_wal/，是一些事务日志信息(transaction log)。这些日志会在定时回滚恢复(PITR)， 流复制(Replication Stream)以及归档时能被用到。
预写日志是保证数据完整性的一种标准方法。在 PostgreSQL中需要对数据文件进行修改时，必须先写入预写日志信息即只有在预写日志记录完成持久化，并且刷新到永久存储中后，才能更改数据文件。根据这个原不需要在每次提交事务时都将数据刷新到磁盘中。
因为在数据库出现宕机发生数据丢失时，可以重新执行预写日志来达到恢复数据库的目的，所以也可以将预写日志称为重做日志，任何没有写到数据文件中的改动都可以根据日志记录重做
在默认情况下，单个预写日志文件的大小是 16MB。单个预写日志文件的大小由参数 walsegment_size 决定。
postgres=# show wal_segment_size;
使用源码进行编译安装时，可以通过指定以下参数更改预写日志文件的大小。
./configure --with-wal-segsize= target_value
默认保存在$PGDATA/pg_wal目录下。
文件名称为16进制的24个字符组成，每8个字符一组，每组的意义如下：
00000001 00000000 00000001
时间线 逻辑ID 物理ID
在一个预写日志写满之后，会自动切换到下一个预写日志文件，可以手动切换。
查看当前预写日志文件
postgres=# select * from pg_ls_waldir();
切换预写日志文件
postgres=# select pg_switch_wal();
再次查看
postgres=# select * from pg_ls_waldir();
查看文件目录
PostgreSOL 使用预写日志的优势。
数据恢复：在系统崩溃时，PostgreSQL可以利用WAL来恢复未提交的事务，从而保证数据的一致性。
减少I/O开销，在提交事务操作时，仅把预写日志写入磁盘，并不会将数据写入磁盘。预写日志写入为连续进行 I/O，而数据写入为随机进行 I/O。因此，预写日志写入的花销小得多。
异地备份：WAL文件可以用来在异地备份数据库。
复制：WAL也是在数据库复制中保持主从同步的关键。
高可用性和故障转移：在高可用性（HA）集群中，WAL也能确保快速的故障转移和恢复。
PostgreSQL中启用和配置WAL：
-- 修改postgresql.conf文件
wal_level = 'replica' -- 设置WAL级别为replica，这是最基本的备份和恢复要求
fsync = on -- 通过强制同步方式来实现数据安全保证
max_wal size =1GB -- 指定WAL日志的空间上限。保证WAL不会占用太多的空间。
min_wal size =80MB -- 该值通常不要设置得太小，容易导致Standby失效。
max_wal_senders = 3 -- 最多同时可以有3个WAL发送进程
wal_sender_timeout = 60s -- WAL发送器如果60秒内没有数据发送，则超时
参数 wal_level可选的值有以下3个，级别依次增高，记录的预写日志信息也依次增多
minimal: 仅写入崩溃或者突发关机时所需要的信息，不能通过基础备份和预写日志恢复数据库。
replica:该级别支持预写日志归档和复制。
logical:在replica级别的基础上添加了支持逻辑解码所需的信息。
当预写日志文件的大小超过参数max_wal size 设置的值时，将发生预写日志信息的覆提示盖，从而造成日志信息的丢失。为了保证数据安全，建议在生产环境中开启预写日志的归档模式。
通过pg_waldump命令可以获取预写日志文件中的记录信息
[postgres@pgserver01 pg_wal]$ pg_waldump 000000010000000000000003
（4）服务器日志
如果用pg_ctl启动时没有使用参数-l来指定服务器日志，那么错误可能会输出到cmd前台。
使用参数-l参数启动生成服务器日志。
[postgres@pgserver01 pgsql]$ pg_ctl -D $PGDATA -l logfile start
启动后在$PGHOME目录下看到服务器日志文件logfile。
（5 ）控制文件
PostgreSQL的控制文件是一个小型的数据库文件，它包含了启动数据库实例所需的关键信息，比如数据库id，是否open，wal的位置，checkpoint的位置等等。控制文件通常位于数据目录中，并且文件名通常为pg_control。
控制文件包含以下关键信息：
数据库系统状态
日志序列号
检查点信息
最后一个检查点的 REDO 位置
最后一个日志段的起始位置
由于控制文件的信息对于数据库的正常运行至关重要，因此在处理PostgreSQL相关问题时，了解如何处理控制文件的备份和恢复是非常重要的。
控制文件的位置：$PGDATA/global/pg_control，可以使用命令bin/pg_controldata查看控制文件的内容，如下：
[postgres@pghost01 data]$ ls $PGDATA/global/pg_control
使用命令bin/pg_controldata查看控制文件的内容
[postgres@pgserver01 pgsql]$ bin/pg_controldata
（6）参数文件
参数文件主要包括postgresql.conf、pg_hba.conf和pg_ident.conf这三个参数文件。
查询系统配置文件存放路径
postgres=# select name,setting,context from pg_settings where category='File Locations';
postgres=# show config_file;
( A). postgresql.conf
和Oracle的pfile，MySQL的my.cnf类似。
– $PGDATA/postgresql.conf
开启参数include_dir = ‘conf.d’可使用$PGDATA/.conf.d/custom.conf
开启参数include_if_exists = 'exists.conf'并存在可使用$PGDATA/exists.conf
开启参数#include = 'special.conf’可使用$PGDATA/special.conf
数据库启动时，会读取该文件
postgresql.conf后面相同的配置项覆盖前面的。
(B). postgresql.auto.conf文件
由postgres服务维护, 能够在关闭和启动期间持续进行更改，可以实现自我调整参数值. 支持文本编辑器修改但不推荐；
alter system命令修改的参数保存在该文件。
postgresql.auto.conf 的值覆盖 postgresql.conf 的值。
(C) pg_hba.conf
类似于防火墙的工具用来控制客户端的访问。通过配置该文件，能够指定哪些ip可以访问，哪些ip不可以访问，以及访问的资源 和认证方式。
该文件位于PostgreSQL的数据目录下，默认路径$PGDATA/pg_hba.conf
文件中的每条规则都遵循一个固定的格式。
# TYPE DATABASE USER ADDRESS METHOD
TYPE：指定规则的类型。 常见的有local（本地连接）、host（TCP/IP连接）和hostssl（仅限SSL加密的TCP/IP连接）。hostnossl不能使用SSL TCP/IP连接。
DATABASE： DATABASE 表示数据库名称,值可能为：
all , sameuser, samerole, replication, 数据库名称 ,或者多个数据库名称用 逗号，注意ALL不匹配 replication。
USER： USER 表示用户名称，值可以为：
all, 一个用户名，一组用户名 ，多个用户时，可以用 ,逗号隔开，
或者在用户名称前缀 + ;在USER和DATABASE字段，也可以写一个单独的。文件名称用 @ 前缀，该文件包含数据库名称或用户名称
ADDRESS： 该参数可以为 主机名称 或者IP/32(IPV4) 或 IP/128(IPV6)，主机名称以 .开头，samehost或samenet 匹配任意Ip地址。
METHOD： 认证方式： "trust", "reject", "md5", "password", "scram-sha-256", "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert"
客户端采用的认证方式，比如trust为无条件地允许联接；reject为无条件拒绝连接；password 为明文密码验证; md5密文密码验证；password明文密码等。
scram-sha-256认证是基于SASL协议的，SASL协议提供一个认证框架，在此框架下可嵌入各 种认证实现。
修改该配置文件中的参数，必须重启 postgreSql服务,若要允许其它IP地址访问该主机数据库，则必须修改 postgresql.conf 中的参数 listen_addresses 为 *。
pg_ctl reload 或者执行 SELECT pg_reload_conf()
(D) pg_ident.conf
pg_ident.conf是用户映射配置文件，用来配置哪些操作系统用户可以映射为数据库用户。结合pg_hba.conf中，method为ident可以用特定的操作系统用户和指定的数据库用户登录数据库。
(E)
- 参数的分类
--数据字典 SELECT name, setting, unit, context FROM pg_settings；
--分类详解
postmaster:该类参数更改配置项后，需要重启PostgreSQL实例才能生效，类似于Oracle里面的静态参数。
superuser-backend：该类参数可以由超级用户来改变，可以在postgresql.conf中对这些设置进 行更改，而无需重新启动服务器。但新的配置值只会出现在这之后的连接中，在已有的连接中， 这些值不会改变。
user:该类参数表示，普通用户可以通过set命令来更改参数的配置值,除了普通用户都可以改变 外，这类参数与 superuser 类参数没有区别 SET configparameter TO DEFAULT;
internal:该类参数是内部参数，也就是说，不可以进行修改，除非重新initdb。
backend:可以在postgresql.conf 中对这些设置进行更改，而无需重新启动服务器。但新的配置值只会出现在这之后的连接中，在已有的连接中，这些值不会改变。只需要向postmaster进程发送一个SIGHUP信号，让其重新读取配置文件即可。
pg_ctl reload -D $PGDATA
sighup：在 posgtresql.conf 文件中可改变这些参数的值，不需要重启数据库，只需要向 postmaster 进程发送 SIGHUP 信号，让其重启配置新的参数值就可以了。postmaster 进程接 收到 SIGHUP 信号后，也会向它的子进程发送 SIGHUP 信号，让新的参数值在所有的进程中 都生效。
SELECT pg_reload_conf();
superuser:该类参数可以由超级用户来改变，改变时，只会影响到自身的session，不会影响到 其他的用户。
扫一扫
765
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
