From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Michael Banck <mbanck(at)gmx(dot)net>, Andy Fan <zhihuifan1213(at)163(dot)com> |
Subject: | Re: Purpose of wal_init_zero |
Date: | 2025-01-15 15:51:54 |
Message-ID: | CAJ7c6TMdLtaX-C-vNK0ffmprcRkzDGPyAPmf1xN5PrALJbAkJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Michael,
> My understanding was that if we have pre-allocated wal space (and
> re-cycle already used wal files), we can still write wal records into
> that pre-allocated space and still issue changes to data files as long
> as we don't need to enlarge any. So an out-of-space situation is less
> bad in that case than if we fail to write WAL with ENOSPC.
True, but if we are out of space we are going to crash anyway because
we can't allocate new heap pages, write regular (text) logfiles,
update CLOG and other SLRU-based structures, etc. So if it is "less
bad" the difference seems to be negligible - either way you crash.
Unless I'm missing something of course.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-01-15 16:00:12 | Re: per backend I/O statistics |
Previous Message | Michael Banck | 2025-01-15 14:59:04 | Re: Purpose of wal_init_zero |