On Mon, Oct 24, 2016 at 8:10 AM, <fred...@huitfeldt.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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
