Re: Disable WAL logging to speed up data loading

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Disable WAL logging to speed up data loading
Дата
Msg-id CAD21AoA9oK1VOoUuKW-jEO=Y2nt5kCQKKFgeQwwRUMoh6BE-ow@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Disable WAL logging to speed up data loading  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: Disable WAL logging to speed up data loading  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Список pgsql-hackers
On Mon, Dec 28, 2020 at 4:29 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> 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.
>

Thank you for telling me about the discussion!

The discussion already started on another thread? I think it might be
better to consider it in parallel, if not started yet. We can verify
beforehand that the proposed solutions will really work well together
with backup management tools. And from the user perspective, I wonder
if they would like to see this feature in the same release where
wal_level = none is introduced. Otherwise, the fact that some backup
management tools won’t be able to work together with wal_level = none
will be a big restriction for users. That patch would probably not be
a blocker of this patch but will facilitate the discussion.

Regards,

--
Masahiko Sawada
EnterpriseDB:  https://www.enterprisedb.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pgsql: Fix memory leak in plpgsql's CALL processing.
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: PATCH: Report libpq version and configuration