Re: Disable WAL logging to speed up data loading

On Fri, Jan 8, 2021 at 2:12 PM tsunakawa(dot)takay(at)fujitsu(dot)com
<tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
>
> From: Robert Haas <robertmhaas(at)gmail(dot)com>
> > Were the issues that I mentioned regarding GIST (and maybe other AMs)
> > in the last paragraph of
> > http://postgr.es/m/CA+TgmoZEZ5RONS49C7mEpjhjndqMQtVrz_LCQUkpRW
> > dmRevDnQ(at)mail(dot)gmail(dot)com
> > addressed in some way? That seems like a pretty hard engineering
> > problem to me, and I don't see that there's been any discussion of it.
> > Those are correctness concerns separate from any wal_level tracking we
> > might want to do to avoid accidental mistakes.
>
> Thank you very much for reminding me of this. I forgot I replied as follows:
>
>
> --------------------------------------------------
> Unlogged GiST indexes use fake LSNs that are instance-wide. Unlogged temporary GiST indexes use backend-local sequence values. Other unlogged and temporary relations don't set LSNs on pages. So, I think it's enough to call GetFakeLSNForUnloggedRel() when wal_level = none as well.
> --------------------------------------------------
>
>
> But this is not correct. We have to allow (RM_GIST_ID, XLOG_GIST_ASSIGN_LSN) WAL records to be emitted (by tweaking the filter in XLogInsert()), just like those WAL records are emitted when wal_level = minimal and and other WAL records are not emitted.

I think it's better to have index AM (and perhaps table AM) control it
instead of filtering in XLogInsert(). Because otherwise third-party
access methods that use LSN like gist indexes cannot write WAL records
at all when wal_level = none even if they want.

Regards,

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