oracle 数据库脏块,PostgreSQL缓存脏块的一个奇怪现象

在PostgreSQL 9.3.1中,作者发现了一个异常情况:一个不应被标记为脏的块被错误地标记。通过创建表、插入数据、检查脏块状态、执行checkpoint以及重启数据库,观察到脏块在某些情况下会不正常地出现和消失。尽管检查了缓存读取代码,但未能找出问题原因。这个问题涉及到数据库的缓冲区管理和脏页标记机制。
摘要由CSDN通过智能技术生成

这是我在写程序过程中发现的,一个不应该为脏的块被标记为脏,PostgreSQL 9.3.1。

出现步骤(用UPDATE语句也同样出现)

创建表并插入一条数据

create table t1(c1 integer);

insert into t1 values(1);

此时

postgres=# select * from pg_buffercache where isdirty;

bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount

----------+-------------+---------------+-------------+---------------+----------------+---------+------------

..........若干

196 |       16385 |          1663 |       12896 |             0 |              0 | t       |          1

写出缓存

postgres=# checkpoint ;

CHECKPOINT

postgres=# select * from pg_buffercache where isdirty;

bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount

----------+-------------+---------------+-------------+---------------+----------------+---------+------------

(0 rows)

可以看到脏块已经消失

重启

pg_ctl stop -D ../data

pg_ctl start -D ../data

查询t1

postgres=# select * from t1;

c1

----

1

(1 row)

查看脏块

postgres=# select * from pg_buffercache where isdirty;

bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount

----------+-------------+---------------+-------------+---------------+----------------+---------+------------

86 |       16385 |          1663 |       12896 |             0 |              0 | t       |          1

(1 row)

按理这里不应该是脏块才对

984e807a6cc4b0eaa1c0c9471868b15e.gif

过段时间,此现象消失,再查询它不会出现脏块中。

我查看过读取缓存的代码,目前没有发现。

此外,脏块的标记并不是靠块状态,而是块描述符,描述符是在数据库运行过程之中维护,无法理解怎么会存在这种现象。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值