Re: Are ZFS snapshots unsafe when PGSQL is spreading through multiple zpools?

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: HECTOR INGERTO <hector_25e(at)hotmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: "pgsql-general(at)postgresql(dot)org <pgsql-general(at)postgresql(dot)org>" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Are ZFS snapshots unsafe when PGSQL is spreading through multiple zpools?
Date: 2023-01-18 10:02:16
Message-ID: c2a914a133284e8abcb5acf6c9c0599326cfb54a.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 2023-01-17 at 15:22 +0000, HECTOR INGERTO wrote:
> > Another case: a transaction COMMITs, and a slightly later transaction reads the data
> > and sets a hint bit.  If the snapshot of the file system with the data directory in it
> > is slightly later than the snapshot of the file system with "pg_wal", the COMMIT might
> > not be part of the snapshot, but the hint bit could be.
> >
> > Then these uncommitted data could be visible if you recover from the snapshot.
>  
> Thank you all. I have it clearer now.
>  
> As a last point. Making the snapshot to the WAL dataset first or last would make any difference?

Imagine you run DROP TABLE. During the implicit COMMIT at the end of the statement,
the files behind the table are deleted. If the snapshot of "pg_wal" is earlier than
the snapshot of the data files, you end up with a table that is not yet dropped,
but the files are gone.

I won't try to find an example if you now ask what if no checkpoint ends between the
statements, the snapshot on "pg_wal" is earlier and we don't run DROP TABLE.

Why do you go to all this effort rather than performing a correct backup?

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Amit Kapila 2023-01-18 11:26:47 Re: Support logical replication of DDLs
Previous Message Laurenz Albe 2023-01-18 08:27:02 Re: minor bug