Re: AW: [Extern] Re: consistent postgresql snapshot

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.

In response to

Responses

Browse pgsql-general by date

  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