Re: 011_crash_recovery.pl failes using wal_block_size=16K

Oops! I forgot that the issue starts from this mail.

At Thu, 4 Mar 2021 22:34:38 +0800, "walker" <failaway(at)qq(dot)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-&gt;safe_psql('postgres'), qq[SELECT pg_xact_status('$xid');]),
> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'in progress', 'own xid is in-progress');
>
>
> sleep(1); &nbsp;# here new added,&nbsp;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