Hi
> I mean basicly the wals should contain the changes, and vacuum full changes the location of the data and not actually
thedata.
Row location is data. For example, index lookup relies on TID (tuple id, hidden ctid column) - physical row address in
datafile.
Postgresql WAL - it is about physical changes in datafiles (block level), not logical. Just moving one row to another
placewithout logical changes means: mark row deleted in old place, write to new place and update every index which
containsthis row.
And vacuum full does not change location, it create copy in different datafile. Then it rebuild every index because TID
wasobviously changed. Then vacuum full drop old datafiles. Full size of new datafile and indexes should be written to
WAL,because all of this is changes and must be reliable written (and then can be replayed on replicas).
> but I didn't find anything about it in the documentation
hmm, i can not found something exact in documentation about it.. It's my knowledge about postgresql internals.
You can read this article:
https://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/
Itsabout WAL logic. All IO operations use pages, and difference between pages written to WAL.
For example, full_page_writes setting (
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-FULL-PAGE-WRITES) say about pages too.
> writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint.
If you want change few bytes in page - the whole page (8kb typical) will be written to WAL during first change of this
pageafter checkpoint.
regards, Sergei
