Tom,
Given what you say below, I think there is a documentation bug then. In
Section 9.3 of the Administrators Guide it says:
"After a checkpoint has been made, any log segments written before the
redo record are removed, so checkpoints are used to free disk space
in the WAL directory."
This should be changed to correctly document the current functionality,
which is essentially something like: "After a checkpoint has been made,
log segments written before the redo record *may* be removed if they
don't contain data for active transactions... " (and IIRC the code
actually keeps the logs around for two checkpoints before attempting to
delete them). The current doc really implies that the fix the disk
space usage problem you need more frequent checkpoints, but as this case
points out that may not fix the problem.
thanks,
--Barry
Tom Lane wrote:
> webb sprague <wsprague@o1.com> writes:
>
>> Unfortunately, the problem snow seems to happen when I vacuum-analyze
>> after a big delete. Even if the vacuum takes more than 2 minutes (the
>> amount of time between flushes that I set in postgresql.conf), the
>> logs continue to grow.
>
>
> I don't think there's any way around that at the moment :-(. The old
> log segments cannot be deleted as long as they include information about
> as-yet-uncommitted transactions, and the VACUUM is one big transaction.
>
> It would theoretically be possible to delete old log segments from
> before the last checkpoint (or better, next-to-last checkpoint) if
> we were only concerned about using the logs for crash recovery.
> I imagine Vadim will object to that, however, since he has in mind
> using the logs for UNDOing aborted transactions sometime soon.
>
> A more likely solution path will be to eliminate VACUUM or break it
> into smaller transactions...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>