Re: [HACKERS] WAL logging problem in 9.4.3?

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: [HACKERS] WAL logging problem in 9.4.3?
Дата
Msg-id 20200227.160024.1603714516899165010.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] WAL logging problem in 9.4.3?  (Noah Misch <noah@leadboat.com>)
Ответы Re: [HACKERS] WAL logging problem in 9.4.3?  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
At Tue, 25 Feb 2020 21:36:12 -0800, Noah Misch <noah@leadboat.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@leadboat.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



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [Patch] Make pg_checksums skip foreign tablespace directories
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Crash by targetted recovery