From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tsunakawa(dot)takay(at)fujitsu(dot)com |
Cc: | osumi(dot)takamichi(at)fujitsu(dot)com, sawada(dot)mshk(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, laurenz(dot)albe(at)cybertec(dot)at, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Disable WAL logging to speed up data loading |
Date: | 2021-01-13 08:12:55 |
Message-ID: | 20210113.171255.1152741719204412097.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 13 Jan 2021 06:01:34 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
> From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> > XLogBeginInsert();
> > XLogSetRecrodFlags(XLOG_MARK_ESSENTIAL); # new flag value
> > XLOGInsert(....);
>
> Oh, sounds like a nice idea. That's more flexible by allowing WAL-emitting modules to specify which WAL records are mandatory even when wal_level is none.
>
> For example, gistXLogAssignLSN() adds the above flag like this:
>
> XLogBeginInsert();
> XLogSetRecordFlags(XLOG_MARK_UNIMPORTANT | XLOG_MARK_ESSENTIAL);
> XLogRegisterData((char *) &dummy, sizeof(dummy));
>
> (Here's a word play - unimportant but essential, what's that?)
Hmm. Food may not be important to someone but it is essential for
survival. I think this is somethig like that :p
> And the filter in XLogInsert() becomes:
>
> + if (wal_level == WAL_LEVEL_NONE &&
> + !((rmid == RM_XLOG_ID && info == XLOG_CHECKPOINT_SHUTDOWN) ||
> + (rmid == RM_XLOG_ID && info == XLOG_PARAMETER_CHANGE) ||
> + (rmid == RM_XACT_ID && info == XLOG_XACT_PREPARE) ||
> + (curinsert_flags & XLOG_MARK_ESSENTIAL)))
>
> Or,
>
> + if (wal_level == WAL_LEVEL_NONE &&
> + !(curinsert_flags & XLOG_MARK_ESSENTIAL))
>
> and add the new flag when emitting XLOG_CHECKPOINT_ONLINE,
Yeah, I was going to comment about that. Skipping the record makes
controlfile filled by a bogus checkpoint location.
> XLOG_PARAMETER_CHANGE and XLOG_PREPARE records. I think both have
> good reasons: the former centralizes the handling of XACT and XLOG
> RM WAL records (as the current XLOG module does already), and the
> latter delegates the decision to each module. Which would you
> prefer? (I kind of like the former, but this is a weak opinion.)
Unfortunately, I prefer the latter as it is simple because it is in a
hot path. As I think I mentioned upthread, I think the xlog stuff
should refrain from being conscious of things deeper than RMger-ID
level. One of other reasons is that generally the issuer site is the
authoritative about the importance and essentiality of a record being
issued. And I don't think it's very good to do the same thing in
different ways at the same time. Fortunately each type of the recrods
has only few issuer places.
By the way, I noticed that pg_switch_wal() silently skips its
task. Desn't it need to give any sort of ERROR?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-01-13 08:22:49 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |
Previous Message | Hou, Zhijie | 2021-01-13 08:00:07 | RE: Single transaction in the tablesync worker? |