RE: Enhance traceability of wal_level changes for backup management

From: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
To: 'David Steele' <david(at)pgmasters(dot)net>
Cc: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, 'Peter Eisentraut' <peter(dot)eisentraut(at)enterprisedb(dot)com>, 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Enhance traceability of wal_level changes for backup management
Date: 2021-03-12 07:25:16
Message-ID: TYAPR01MB299030002E4673DD46DCBEF9FE6F9@TYAPR01MB2990.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: David Steele <david(at)pgmasters(dot)net>
> As a backup software author, I don't see this feature as very useful.
>
> The problem is that there are lots of ways for WAL to go missing so
> monitoring the WAL archive for gaps is essential and this feature would
> not replace that requirement. The only extra information you'd get is
> the ability to classify the most recent gap as "intentional", maybe.

But how do you know there's any missing WAL? I think there are the following cases of missing WAL:

1. A WAL segment file is missing. e.g., 00000001 and 00000003 exist, but 00000002 doesn't.

2. All consecutive WAL segment files appear to exist, but some WAL records are missing.
This occurs ?only? when some WAL-optimized statements are run while wal_level = minimal.

Currently, backup management tools can detect 1 by scanning through the WAL archive directory. But the can't notice 2. The patch addresses this.

This is what some other people suggested in the thread for wal_level = none that Osumi-san referred to at the beginning of this thread. I don't think this detection feature is not a blocker for wal_level = none. So, I think this can be withdrawn if wal_level = none can be accepted.

Regards
Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-12 07:45:47 Re: Different compression methods for FPI
Previous Message Greg Nancarrow 2021-03-12 07:23:54 Re: Parallel INSERT (INTO ... SELECT ...)