From: | Sergey Burladyan <eshkinkot(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Victor Yagofarov <xnasx(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why standby restores some WALs many times from archive? |
Date: | 2017-12-31 07:22:37 |
Message-ID: | 87a7xztl8i.fsf@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Sat, Dec 30, 2017 at 04:30:07AM +0300, Sergey Burladyan wrote:
> > We use this scripts:
> > https://github.com/avito-tech/dba-utils/tree/master/pg_archive
> >
> > But I can reproduce problem with simple cp & mv:
> > archive_command:
> > test ! -f /var/lib/postgresql/wals/%f && \
> > test ! -f /var/lib/postgresql/wals/%f.tmp && \
> > cp %p /var/lib/postgresql/wals/%f.tmp && \
> > mv /var/lib/postgresql/wals/%f.tmp /var/lib/postgresql/wals/%f
>
> This is unsafe. PostgreSQL expects the WAL segment archived to be
> flushed to disk once the archive command has returned its result to the
> backend.
Yes, you are right, thank you for pointing that out! I upload new
version with sync to github.
> Don't be surprised if you get corrupted instances or that you
> are not able to recover up to a consistent point if you need to roll in
> a backup.
But only if archive was reboot unexpectedly, am I right?
--
Sergey Burladyan
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-12-31 07:52:54 | Re: Converting plpgsql to use DTYPE_REC for named composite types |
Previous Message | Pavan Deolasee | 2017-12-31 06:44:02 | Faster inserts with mostly-monotonically increasing values |