Re: strange behavior of WAL files

From: Atul Kumar <akumar14871(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: strange behavior of WAL files
Date: 2021-06-04 15:10:30
Message-ID: CA+ONtZ5WnVu4BmQtB5Aw4UapEpG9citT69cXn60=w_GdAyY9Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Jehan,

Just to add little more info about this issue is : We have set value
4000 for parameter wal_keep_segments.

So is there any chance that after a certain number of WAL files,
postgres will start recycling the WAL with same name ?

Please share your valuable suggestion.

Regards.
Atul

On 6/4/21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Atul Kumar <akumar14871(at)gmail(dot)com> writes:
>> once old WAL files of pg_xlog directory are archived in
>> '/nfslogs/wal/' directory then these WAL files are getting generated
>> with the same name in pg_xlog directory.
>
> Are you sure you are describing the behavior accurately?
>
> What I would expect to happen, once an old WAL file has been archived
> and the server knows its contents are no longer needed, is for the
> WAL file to be "recycled" by renaming it to have a name that's in-the-
> future in the WAL name series, whereupon it will wait its turn to be
> reused by future WAL writes. On most filesystems the rename as such
> doesn't change the file's mod time, so you'll see files that seem
> to be in-the-future according to their names, but have old timestamps.
>
> (There's a limit on how many future WAL files we'll tee up this way,
> so it's possible that an old one would just get deleted instead.
> But the steady-state behavior is to just rotate them around.)
>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joe Conway 2021-06-04 15:20:50 Re: EXCLUDE USING and tstzrange
Previous Message Laura Smith 2021-06-04 14:58:56 Re: EXCLUDE USING and tstzrange