From: | Nick Cleaton <nick(at)cleaton(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Zwettler Markus (OIZ)" <Markus(dot)Zwettler(at)zuerich(dot)ch>, Ron <ronljohnsonjr(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: AW: [Extern] Re: consistent postgresql snapshot |
Date: | 2022-05-12 14:53:22 |
Message-ID: | CAFgz3ktDYV7gn+wAoYzfQebW9ckw07s-yHufRVdDYNgfbNxdtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 12 May 2022 at 14:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Zwettler Markus (OIZ)" <Markus(dot)Zwettler(at)zuerich(dot)ch> writes:
> > I don't want to do use the normal backup algorithm where pg_start_backup
> + pg_stop_backup will fix any fractured block and I am required to have all
> archived logfiles, therefore.
> > I want to produce an atomic consistent disk snapshot.
>
> [ shrug... ] You can't have that. [snip]
>
> The only way you could get a consistent on-disk image is to shut
> the server down (being sure to do a clean not "immediate" shutdown)
> and then take the snapshot.
>
I think you could work around that by taking a dirty snapshot, making a
writable filesystem from it, waiting until you've archived enough WAL to
get that to a consistent state, and then firing up a temporary postmaster
on that filesystem to go through recovery and shut down cleanly.
From | Date | Subject | |
---|---|---|---|
Next Message | Hugh Ranalli | 2022-05-12 15:03:48 | Re: effects of nullifying bytea column on storage |
Previous Message | alias | 2022-05-12 14:48:23 | Re: Deferred constraint trigger semantics |