Re: Unarchived WALs deleted after crash

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Unarchived WALs deleted after crash
Date: 2013-02-20 15:05:00
Message-ID: 5124E61C.7090202@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a quick top-post to thank you all for this fix guys !

Cheers,

On 15/02/2013 18:43, Heikki Linnakangas wrote:
> On 15.02.2013 19:16, Fujii Masao wrote:
>> On Sat, Feb 16, 2013 at 2:07 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> On 15.02.2013 18:10, Fujii Masao wrote:
>>>>
>>>> At least in 9.2, when the archived file is restored into
>>>> pg_xlog, its xxx.done archive status file is created. So we
>>>> don't need to check InArchiveRecovery when deleting old WAL
>>>> files. Checking whether xxx.done exists is enough.
>>>
>>> Hmm, what about streamed WAL files? I guess we could go back to
>>> the pre-9.2 coding, and check WalRcvInProgress(). But I didn't
>>> actually like that too much, it seems rather random that old
>>> streamed files are recycled when wal receiver is running at the
>>> time of restartpoint, and otherwise not. Because whether wal
>>> receiver is running at the time the restartpoint happens has
>>> little to do with which files were created by streaming
>>> replication. With the right pattern of streaming files from the
>>> master, but always being teporarily disconnected when the
>>> restartpoint runs, you could still accumulate WAL files
>>> infinitely.
>>
>> Walreceiver always creates .done file when it closes the
>> already-flushed WAL file and switches WAL file to next. So we
>> also don't need to check WalRcvInProgress().
>
> Ah, I missed that part of the patch.
>
> Okay, agreed, that's a better fix. I committed your forward-port of
> the 9.2 patch to master, reverted my earlier fix for this bug, and
> simply removed the
> InArchiveRecovery/ArchiveRecoveryInProgress()/RecoveryInProgress()
> condition from RemoveOldXlogFiles().
>
> - Heikki

- --
Jehan-Guillaume de Rorthais
http://www.dalibo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEk5hwACgkQXu9L1HbaT6JZ3wCg4h7QT+wRMT8KZAA/PjOjZcCV
CS4AnRFeGdXIgklo1/RD2hi+e98pNBEe
=voW3
-----END PGP SIGNATURE-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-02-20 15:14:40 pgsql: Fix pg_dumpall with database names containing =
Previous Message Andres Freund 2013-02-20 14:41:39 Re: CREATE RULE "_RETURN" and toast tables