PostgreSQL的密码文件
发表于|更新于|科技·Tech数据库技术·DatabasesPostgreSQL
|浏览量:
PostgreSQL的密码文件
在用户的Home目录中,.pgpass文件可以包含连接所需的密码(如果没有其他方式指定密码)。在Windows系统中,该文件名为%APPDATA%\postgresql\pgpass.conf(其中%APPDATA%指的是用户配置文件中的应用程序数据子目录)。另外,可以通过连接参数passfile或环境变量PGPASSFILE指定要使用的密码文件。
密码文件的内容如下:
hostname:port:database:username:password
前四个字段可以是字面值,也可以是,即匹配任何内容。将使用与当前连接参数匹配的第一行中的密码字段。(因此,在使用通配符时,请首先放置更具体的条目。)如果条目需要包含:或\,可以使用\来转义这些字符。 主机名字段会与指定时的主机连接参数匹配,否则与指定时的hostaddr参数匹配;如果两者都未给出,则搜索主机名localhost。当连接为Unix域套接字连接,且主机参数与libpq的默认套接字目录路径匹配时,也会搜索主机名localhost。在standby服务器中,数据库字段为replication时,将匹配到主服务器的流复制连接。否则,数据库字段的作用有限,因为用户在同一个集群中的所有数据库使用相同的密码。
在Unix系统中,密码文件的权限必须禁止全局或组访问;可以通过命令如chmod 0600 ~/.pgpass来实现这一点。如果权限未按如此严格配置,文件将被忽略。在Microsoft Windows中,假定文件存储在安全的目录中,因此不进行特殊权限检查。
文章作者: Chan Revival
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Chan Revival Sky!
相关推荐
2024-12-26
谈谈生产环境中PostgreSQL参数的意义
谈谈生产环境中PostgreSQL参数的意义archive_commandarchive_command = ‘$pg_data_dir/../arch.sh %f %p’ auto_explain.log_analyzeauto_explain.log_analyze = true auto_explain.log_min_duration = ‘300ms’ auto_explain.log_min_duration = ‘300mss’ auto_explain.log_timing = on auto_explain.log_verbose = off autovacuum = on autovacuum_analyze_scale_factor = 0.01 autovacuum_freeze_max_age = 1200000000 autovacuum_max_workers = 12 autovacuum_multixact_freeze_max_age = 1250000000autovacuum_vacuum_cost_delay = 0msautovacuum_vacuum_scale_factor = 0.02checkpoint_completion_target = 0.5checkpoint_flush_after = 0checkpoint_timeout = 30mincheckpoint_timeout = 30mindefault_text_search_config =...
2024-12-18
生产环境PostgreSQL数据库操作系统参数探究
生产环境PostgreSQL数据库操作系统参数探究操作系统参数 序号 参数名称 参数值 参数意义 参数值分析 1 fs.aio-max-nr 1048576 系统允许的异步I/O最大请求数,用于支持高并发I/O操作。 值较高,适合高并发环境,如数据库系统大规模读写操作场景。 2 fs.file-max 76724600 系统允许打开的最大文件描述符数量,影响文件和网络连接数量的上限。 值非常高,支持大量并发连接和文件访问,适合数据库服务器场景。 3 kernel.sem 4096 2147483647 2147483646...
2024-11-27
谈谈PostgreSQL数据库的表膨胀
谈谈PostgreSQL数据库的表膨胀什么是PostgreSQL数据库的表膨胀?PostgreSQL 数据库的 表膨胀,简单来说,就是表的数据存储空间变得比实际需要的要大。膨胀现象发生时,虽然表中的数据量没有显著增加,但数据库占用的磁盘空间却比实际数据量大很多。这种现象会影响性能,导致查询速度变慢,并且浪费磁盘空间。 为什么会产生表膨胀?表膨胀的主要原因通常有以下几个: 更新和删除操作导致的“死元组”: PostgreSQL 在执行更新(UPDATE)或删除(DELETE)操作时,不是直接修改或删除原来的数据,而是将旧数据标记为“死元组”,然后在新位置插入新数据。这意味着,原来数据的位置还是被保留在磁盘上,直到进行清理(VACUUM)。如果没有及时执行 VACUUM 操作,死元组就会不断积累,导致表膨胀。 MVCC(多版本并发控制): PostgreSQL 使用多版本并发控制(MVCC)来处理事务。每个事务都会为每一行数据创建一个版本(tuple),并保持旧版本的数据直到事务完全结束。由于事务未提交或者被回滚时,旧版本不会立即清理,造成空间浪费。 索引膨胀: 索引在插入、删除、更新数据时,也会产生膨胀。特别是在大量数据删除或更新后,索引结构没有及时整理,导致索引占用更多空间。 自增列: 对于包含自增列(如 serial 或 bigserial)的表,删除某些数据后,自增的序列号并不会回收,这可能会导致空间浪费。 检查表膨胀情况的两种方法方法一 查询pg_stat_user_tables、pg_total_relation_size表12345678SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size, ...
2024-11-26
PostgreSQL运维常用命令
PostgreSQL运维常用命令查看当前连接的用户名12select * from current_userselect user 给普通用户授权1GRANT USAGE ON SCHEMA sch_user TO usr_user; 查询表大小,不含索引12345db_database=> select pg_size_pretty(pg_relation_size('sch_admin.tab_table0')); pg_size_pretty ---------------- 8192 bytes(1 row) 查询表大小,含索引12345db_database=> select pg_size_pretty(pg_total_relation_size('sch_admin.tab_table0')); pg_size_pretty ---------------- 24 kB(1 row) 查WAL文件12345678910 select *,size/1024/1024 as "MB" from pg_ls_waldir(); name | size | modification | MB --------------------------+----------+------------------------+---- cleanup.log | 463 | 2022-07-28 09:45:36+08 | 0 000000010000000800000011 | 16777216 | 2022-08-24 10:10:01+08 | 16...
2024-11-11
Doris坏盘换盘方法
Doris坏盘换盘方法先换好盘参考其它/data,创建好目录,正确授权。 1234cd /dataxxxmkdir -p /dataxxx/doris-storagechown -R doris:doris /dataxxx/doris-storagell 注释掉坏盘路径1vi /usr/local/doris-be/conf/be_custom.conf 注释掉broken_storage_path。 重启be进程可在Web管理控制台操作。
2024-04-24
如何在ASM 11gR2中重命名磁盘组?
本指南详细展示了在11gR2版本中如何正确重命名ASM磁盘组的步骤。请注意,在操作过程中,应避免使用renamedg命令来重命名OCR/VOTE磁盘组,以免引起不必要的风险。 首先,需要卸载想要重命名的磁盘组(如果是RAC配置,则从每个节点上卸载): 1# asmcmd umount <OLD_DG_NAME> 验证所需的磁盘组是否已卸载: 1234# asmcmd lsdgState Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files NameMOUNTED NORMAL N 512 4096 1048576 32756 31828 244 15792 0 N <OLD_DG_NAME>_OCR/MOUNTED EXTERN N 512 4096 1048576 16378 10134 0 10134 0 N LOB<OLD_DG_NAME>/ 然后执行重命名语句: 12345678910111213141516171819202122232425262728293031323334353637383940# renamedg phase=both dgname=<OLD_DG_NAME> newdgname=<NEW_DG_NAME> verbose=trueParsing parameters..Parameters in effect:Old DG name : <OLD_DG_NAME>New DG name : <NEW_DG_NAME>Phases :Phase 1Phase...
1899-11-30
数据库技术·Databases
PostgreSQL PostgreSQL database blog Oracle Oracle database blog Doris Doris database blog MongoDB MongoDB database blog
2025-03-13
PostgreSQL配置文件中postgresql.conf与postgresql.auto.conf的异同点
在PostgreSQL数据库的日常运维中,配置管理始终是DBA工作的核心环节。随着PostgreSQL 12版本的发布,其配置管理系统在保持传统优势的基础上,进一步强化了动态配置能力。本文将深入剖析postgresql.conf与postgresql.auto.conf两个关键配置文件的技术内涵,通过架构设计、运行机制、实践应用等多维度的对比分析,揭示二者在现代数据库运维体系中的协同关系。 一、配置体系的演进脉络PostgreSQL的配置管理经历了从单一文件到分层管理的演进过程。在早期版本中,所有配置参数都集中在postgresql.conf文件中,这种集中式管理虽然直观,但在动态调整和版本控制方面存在明显局限。自9.4版本引入ALTER SYSTEM命令后,配置体系逐步形成了双轨制管理模式。 在PostgreSQL 12中,这种分层架构达到新的成熟度: 基础配置文件(postgresql.conf):作为声明式配置的载体 自动配置文件(postgresql.auto.conf):记录动态调整的增量配置 内存运行时配置:通过pg_settings视图实时反映 这种三层架构不仅提升了配置的灵活性,更为自动化运维提供了基础设施支持。值得关注的是,postgresql.auto.conf在12版本中强化了原子写入特性,确保在高并发场景下的配置更新可靠性。 二、技术特性的多维度对比2.1 文件生成机制 postgresql.conf:手工创建/编辑,存在于$PGDATA目录 postgresql.auto.conf:由ALTER SYSTEM命令自动生成和维护 案例演示: 12345678-- 执行动态配置修改ALTER SYSTEM SET shared_buffers = '4GB';-- 查看生成的auto.conf\! cat...
评论
公告
若网页打开缓慢,请切换线路(页面顶部)。
If the webpage loads slowly, please switch lines (the option is at the top of the page).
If the webpage loads slowly, please switch lines (the option is at the top of the page).