Re: stale WAL files?

From: Gmail <robjsargent(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: stale WAL files?
Date: 2019-03-29 22:32:29
Message-ID: 24253F34-C773-4DA7-8189-321CA54AB535@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Mar 29, 2019, at 6:58 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
>> On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote:
>> This is pg10 so it's pg_wal. ls -ltr
>>
>>
>> -rw-------. 1 postgres postgres 16777216 Mar 16 16:33
>> 0000000100000CEA000000B1
>> -rw-------. 1 postgres postgres 16777216 Mar 16 16:33
>> 0000000100000CEA000000B2
>>
>> ... 217 more on through to ...
>>
>> -rw-------. 1 postgres postgres 16777216 Mar 16 17:01
>> 0000000100000CEA000000E8
>> -rw-------. 1 postgres postgres 16777216 Mar 16 17:01
>> 0000000100000CEA000000E9
>> -rw-------. 1 postgres postgres 16777216 Mar 28 09:46
>> 0000000100000CEA0000000E
>
> In Postgres 10 and older versions, the server keeps WAL segment for
> the last completed segment, and the previous completed segment. So
> even if a checkpoint is issued, the current WAL insert point is never
> really going to be on the first segment in pg_wal. Isn't that the
> origin of what you think is a problem? So, say, if you issue a
> checkpoint again, don't you see 0000000100000CEA000000B1 going away?
I had CEA000000015, generated today, as only entry since Mar 16. Issued checkpoint, soon had CEA0000016 and 15. Five minutes later I still hav 15 and 16 (and of course all 271 from Mar 16).

>
> In Postgres 11, WAL segments worth only one checkpoint are kept
> around.
> --
> Michael

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ankit Trivedi 2019-03-30 11:09:51 Required postgreSQL 10.4 version for Suse enterprise
Previous Message Peter J. Holzer 2019-03-29 19:53:27 Re: Key encryption and relational integrity