RE: Disable WAL logging to speed up data loading - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Disable WAL logging to speed up data loading
Date
Msg-id OSBPR01MB48881F25E0634C5ACB8B69C9EDD90@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Disable WAL logging to speed up data loading
List pgsql-hackers
Hello Sawada-San


On Monday, December 28, 2020 2:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Thu, Dec 3, 2020 at 12:14 PM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > I've made a new patch v05 that took in comments to filter out WALs
> > more strictly and addressed some minor fixes that were discussed
> > within past few days.
> > Also, I changed the documentations, considering those modifications.
> 
> From a backup management tool perspective, how can they detect that
> wal_level has been changed to ‘none' (and back to the normal)? IIUC once
> we changed wal_level to none, old backups that are taken before setting to
> ‘none’ can be used only for restoring the database to the point before the
> LSN where setting 'wal_level = none'. The users can neither restore the
> database to any points in the term of 'wal_level = none' nor use an old backup
> to restore the database to the point after LSN where setting 'wal_level =
> none’. I think we might need to provide a way to detect the changes other
> than reading XLOG_PARAMETER_CHANGE.
In the past, we discussed the aspect of backup management tool in [1]
and concluded that this should be another patch separated from this thread
because to compare the wal_level changes between snapshots
applies to wal_level = minimal, too. Please have a look at the "second idea"
in the e-mail in the [1] and responses to it.

 [1] -
https://www.postgresql.org/message-id/OSBPR01MB4888B34B81A6E0DD46B5D063EDE00%40OSBPR01MB4888.jpnprd01.prod.outlook.com

Best Regards,
    Takamichi Osumi

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies
Next
From: Peter Geoghegan
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies