Oops! I forgot that the issue starts from this mail.
At Thu, 4 Mar 2021 22:34:38 +0800, "walker" <faila...@qq.com> wrote in
> 011_crash_recovery.pl ..
> 1..3
> ok 1 - own xid is in-progress
> not ok 2 - new xid after restart is greater
> But if I modified something in t/011_crash_recovery.pl, this perl script
> works fine, as follows:
> is($node->safe_psql('postgres'), qq[SELECT pg_xact_status('$xid');]),
> 'in progress', 'own xid is
> in-progress');
>
>
> sleep(1); # here new added, just make sure the CREATE TABLE XLOG
> can be flushed into WAL segment file on disk.
The sleep let the unwriten WAL records go out to disk (buffer).
> I think the problem is that before crash(simulated by stop with immediate
> mode), the XLOG of "create table mine" didn't get flushed into wal file on
> disk. Instead, if delay some time, e.g. 200ms, or more after issue create
> table, in theory, the data in wal buffer should be written to disk by wal
> writer.
Right.
> However, I'm not sure the root cause. what's the difference between
> wal_blocksize=8k and wal_blocksize=16k while flushing wal buffer data to disk?
I'm sorry that I didn't follow this message. However, the explanation
is in the following mail.
https://www.postgresql.org/message-id/20210305.135342.384699732619433016.horikyota.ntt%40gmail.com
In short, the doubled block size prevents wal-writes from happen.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
