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
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 |