Corrupted file investigation

[tdrz]

I am one of the maintainers of PGlite - PostgreSQL in WASM.

As part of some research in refactoring a some of our codebase, I am experiencing what looks like a filesystem corruption. I see the same behavior both with MEMFS and NODEFS.

This happens with initdb which creates multiple directories and initial database files. During the last step of the initialization, I am seeing this error:

2025-12-08 19:00:53.385 +01 [42] FATAL:  invalid page in block 0 of relation base/1/3439
2025-12-08 19:00:53.385 +01 [42] CONTEXT:  while scanning block 0 of relation "pg_toast.pg_toast_3381"
2025-12-08 19:00:53.385 +01 [42] STATEMENT:  VACUUM FREEZE;

The file base/1/3381 is 0 bytes long, which is incorrect (confirmed by comparing with the data produced by our current release). Perhaps of interest, by varying some initdb/postgres (eg --with-blocksize=X) configure parameters the invalid page error can happen in a different file. I can see the debug messages where the corresponding files are created and even fsync'ed to the FS:

DEBUG:  creating relation pg_statistic_ext 3381
...
DEBUG:  relation created with OID 3381
...
DEBUG:  creating toast table for table "pg_statistic_ext"
...
DEBUG:  checkpoint sync: number=68 file=base/1/3381 time=0.004 ms

I am using emcc version 3.1.74.

I am not modifying PostgreSQL's code in any meaningful way, so I am thinking that some FS interaction might be the culprit.

How can I investigate this further and how could I fix it?

[sbc100]

I think narrowing down the failure to something as small as possible and as reproducible as possible is the best way to start looking into this. Sorry, I'm able to be much more specific at this point.

Also, if this used to work but stopped working at some point then we can look into bisecting which could point at the culprit directly.

[tdrz]

I think narrowing down the failure to something as small as possible and as reproducible as possible is the best way to start looking into this. Sorry, I'm able to be much more specific at this point.

I understand, thank you. That won't be easy though...

Also, if this used to work but stopped working at some point then we can look into bisecting which could point at the culprit directly.

This is a new approach, the working version is quite different (wrt the code itself; using same emscripten build flags) from my attempt.

I'll close this for now, but if anything comes to mind related to filesystem handling, please let me know.