Re: checkpoint occurs very often when vacuum full running

Hi Laurenz.
thank you for the explanation but I still got a few questions about this
subject :
1.By physical location of the data do you mean the location on disk of the
objects ? I mean i thought that the wal files containing the logical
changes , for example If I run an update then the wal file will contain the
update in some format. Can you explain then what exactly it contains and
what you meant by physical ?
2.So If the vacuum full stopped in some brutal way (kill -9 or the disk run
of space) does all the new data files that are created deleted or left on
the storage as orphan files ?

Thanks, Mariel.

‫בתאריך יום ה׳, 15 בנוב׳ 2018 ב-22:32 מאת ‪Laurenz Albe‬‏ <‪
laurenz(dot)albe(at)cybertec(dot)at‬‏>:‬

> Mariel Cherkassky wrote:
> > First of all thank you for the quick answer. In my case checkpoint
> happened
> > every one second during the vacuum full so the checkpoint timeout isn't
> relevant.
> > My guess was that it writes the changes to the wals but I didn't find
> anything
> > about it in the documentation. Can you share a link that proves it ?
> > I mean basicly the wals should contain the changes, and vacuum full
> changes
> > the location of the data and not actually the data.
>
> VACUUM (FULL) completely rewrites all the tables and indexes, so the
> complete
> database will go into the WAL (these data changes have to be replayed in
> case
> of a crash!). WAL contains the physical and not the logical changes, and
> the
> physical data *are* modified.
>
> You should let autovacuum do the job instead of running VACUUM (FULL),
> unless
> your whole database is bloated beyond tolerance. That will cause less WAL
> activity and also won't disrupt normal database operation.
>
> If you really need that VACUUM (FULL), you can increase "max_wal_size" to
> get fewer checkpoints.
>
> Yours,
> Laurenz Albe
> --
> Cybertec | https://www.cybertec-postgresql.com
>
>