Message-ID: <1f40f551ce8f21ea67e63fc357098c116cbcb1f0.camel@cybertec.at>
Subject: Re: q re removal/recycling of WAL files
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Scott Ribe <scott_ribe@elevated-dev.com>, pgsql-admin
	 <pgsql-admin@lists.postgresql.org>
Date: Thu, 04 Nov 2021 00:38:12 +0100
In-Reply-To: <4B485D8E-9692-4009-8562-43BC0E54C975@elevated-dev.com>
References: <4B485D8E-9692-4009-8562-43BC0E54C975@elevated-dev.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/1f40f551ce8f21ea67e63fc357098c116cbcb1f0.camel%40cybertec.at>
Precedence: bulk

On Wed, 2021-11-03 at 16:24 -0600, Scott Ribe wrote:
> Let's say that there's a big update as part of a migration, and that update times out,
> and the migration utility retries it several times. (Context is that sequence happened
> through automated utility, and filled the disk, leading to an unfortunate series of events.)
> 
> 1) At what point does WAL from the failed & rolled back operations "go away"? During the next
>    checkpoint? During the checkpoint after completion of all other transactions which
>    overlapped time-wise with the timing-out ones?

A WAL segment is deleted if it contains no record newer than the latest checkpoint
or the oldest replication slot, and it is archived (if enabled) and "wal_keep_size"
does not require it to be kept around. 

That is the same for committed and rolled back operations.

> 2) Is there a chance that never-visible rows would be written into tables, bloating them?

Yes, that will definitely happen.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com