Message-ID: <e2734466-50a2-4b7a-91a7-b141e9d16b93@enterprisedb.com>
Date: Fri, 8 Mar 2024 16:40:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Identify transactions causing highest wal generation
Content-Language: en-US
To: Gayatri Singh <gayatripremselvi@gmail.com>,
 pgsql-hackers@lists.postgresql.org
References: <CABDbDcbgo8dz73fsjt5JFc19BLR2h9JNwou7KxWwKEpJc0hAAw@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <CABDbDcbgo8dz73fsjt5JFc19BLR2h9JNwou7KxWwKEpJc0hAAw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/e2734466-50a2-4b7a-91a7-b141e9d16b93%40enterprisedb.com>
Precedence: bulk

On 3/8/24 15:50, Gayatri Singh wrote:
> Hello Team,
> 
> Can you help me with steps to identify transactions which caused wal
> generation to surge ?
> 

You should probably take a look at pg_waldump, which prints information
about WAL contents, including which XID generated each record.

I don't know what exactly is your goal, but sometimes it's not entirely
direct relationship. For example, a transaction may delete a record,
which generates just a little bit of WAL. But then after a checkpoint a
VACUUM comes around, vacuums the page to reclaim the space of the entry,
and ends up writing FPI (which is much larger). You could argue this WAL
is also attributable to the original transaction, but that's not what
pg_waldump will allow you to do. FPIs in general may inflate the numbers
unpredictably, and it's not something the original transaction can
affect very much.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company