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