Re: strange behavior of WAL files

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Atul Kumar <akumar14871(at)gmail(dot)com>
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-05 19:44:46
Message-ID: 561515.1622922286@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Atul Kumar <akumar14871(at)gmail(dot)com> writes:
> Please check my findings below

> older
> -rw------- 1 enterprisedb enterprisedb 16777216 Jun 2 02:47
> 00000001000036CF000000A4
> -rw------- 1 enterprisedb enterprisedb 16777216 Jun 2 02:45
> 00000001000036CF000000A3
> -rw------- 1 enterprisedb enterprisedb 16777216 Jun 2 02:44
> 00000001000036CF000000A5

I suspect these files were archived awhile ago (with different
names) and have already been renamed in preparation for using
them as future WAL segments ...

> -rw------- 1 enterprisedb enterprisedb 16777216 Jun 4 08:23
> 00000001000036CF000000A3
> -rw------- 1 enterprisedb enterprisedb 16777216 Jun 4 08:23
> 00000001000036CF000000A4

... and here we see that they just got overwritten with new WAL data,
which would make their new contents eligible for archiving.

Have you made any attempt to correlate your observations with
the actual WAL write position? (pg_controldata would give you
at least a rough approximation of that, i.e. the WAL write
position as of the most recent checkpoint. I think you can
get a more up-to-date result from one or another system view,
but I don't remember which.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Achilleas Mantzios 2021-06-05 20:10:30 Re: Ideas for building a system that parses medical research publications/articles
Previous Message Adrian Klaver 2021-06-05 19:12:48 Re: Ideas for building a system that parses medical research publications/articles