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
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 |