Re: [HACKERS] WAL logging problem in 9.4.3?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: noah(at)leadboat(dot)com
Cc: robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, 9erthalion6(at)gmail(dot)com, andrew(dot)dunstan(at)2ndquadrant(dot)com, hlinnaka(at)iki(dot)fi, michael(at)paquier(dot)xyz
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Date: 2020-02-27 07:00:24
Message-ID: 20200227.160024.1603714516899165010.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 25 Feb 2020 21:36:12 -0800, Noah Misch <noah(at)leadboat(dot)com> wrote in
> On Tue, Feb 25, 2020 at 10:01:51AM +0900, Kyotaro Horiguchi wrote:
> > At Sat, 22 Feb 2020 21:12:20 -0800, Noah Misch <noah(at)leadboat(dot)com> wrote in
> > > On Fri, Feb 21, 2020 at 04:49:59PM +0900, Kyotaro Horiguchi wrote:
> > I aggree that the new #ifdef can invite a Heisenbug. I thought that
> > you didn't want that because it doesn't make substantial difference.
>
> v35nm added swap_relation_files() code so AssertPendingSyncs_RelationCache()
> could check rd_droppedSubid relations. v30nm, which did not have
> rd_droppedSubid, removed swap_relation_files() code that wasn't making a
> difference.

Ok, I understand that it meant that the additional code still makes
difference in --enable-cassert build.

> > If we decide to keep the consistency there, I would like to describe
> > the code is there for consistency, not for the benefit of a specific
> > assertion.
> >
> > (cluster.c:1116)
> > - * new. The next step for rel2 is deletion, but copy rd_*Subid for the
> > - * benefit of AssertPendingSyncs_RelationCache().
> > + * new. The next step for rel2 is deletion, but copy rd_*Subid for the
> > + * consistency of the fieles. It is checked later by
> > + * AssertPendingSyncs_RelationCache().
>
> I think the word "consistency" is too vague for "consistency of the fields" to
> convey information. May I just remove the last sentence of the comment
> (everything after "* new.")?

I'm fine with that:)

> > I agree that relation works as the generic name of table-like
> > objects. Addition to that, doesn't using the word "storage file" make
> > it more clearly? I'm not confident on the wording itself, but it will
> > look like the following.
>
> The docs rarely use "storage file" or "on-disk file" as terms. I hesitate to
> put more emphasis on files, because they are part of the implementation, not
> part of the user interface. The term "rewrites"/"rewriting" has the same
> problem, though. Yet another alternative would be to talk about operations
> that change the pg_relation_filenode() return value:
>
> In <literal>minimal</literal> level, no information is logged for permanent
> relations for the remainder of a transaction that creates them or changes
> what <function>pg_relation_filenode</function> returns for them.
>
> What do you think?

It sounds somewhat obscure. Coulnd't we enumetate examples? And if we
could use pg_relation_filenode, I think we can use just
"filenode". (Thuogh the word is used in the documentation, it is not
defined anywhere..)

====
In <literal>minimal</literal> level, no information is logged for
permanent relations for the remainder of a transaction that creates
them or changes their <code>filenode</code>. For example, CREATE
TABLE, CLUSTER or REFRESH MATERIALIZED VIEW are the command of that
category.
====

# sorry for bothering you..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-02-27 07:23:44 Re: Crash by targetted recovery
Previous Message Michael Paquier 2020-02-27 06:48:21 Re: [Patch] Make pg_checksums skip foreign tablespace directories