From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | fredrik(at)huitfeldt(dot)com |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: out-of-order XID insertion in KnownAssignedXids |
Date: | 2016-10-24 13:59:06 |
Message-ID: | CACjxUsNo3nAFhAL7oEL-ratOGp=-FLGFfPGquzE5VdcuQosm3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Oct 24, 2016 at 8:10 AM, <fredrik(at)huitfeldt(dot)com> wrote:
> This was actually introduced some time back, and I am not completely certain
> how it crept into our codebase. I think that at least part of the
> explanation lies in the fact that we are experiencing a fair amount of
> growth in the database size and use on some of our installations. This could
> be the reason why extensive testing did not show the issue back then and why
> we are seeing it now.
If there is no checkpoint during the backup, you dodge the
corruption. Higher update volume increases the frequency of
checkpoints and larger cluster size makes the backup take longer --
either of which would make corruption more likely.
> Would it make sense to log a warning in the case of a missing backup_label
> file, or would it be difficult to identify that situation in the code?
The problem is, without a backup_label file things look exactly
like a crash recovery, which is why it just goes to the last usable
checkpoint; that's the correct behavior for crash recovery.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-10-24 15:07:38 | Re: SERIALIZABLE and INSERTs with multiple VALUES |
Previous Message | fredrik | 2016-10-24 13:10:41 | Re: out-of-order XID insertion in KnownAssignedXids |