Re: Fix for segfault in logical replication on master

Поиск
Список
Период
Сортировка
Искать
От
Mark Dilger
Тема
Re: Fix for segfault in logical replication on master
Дата
Msg-id
FCF0D585-0B9E-458E-82FC-11AAB0BFD1A0@enterprisedb.com
Ответ на
Список
Дерево обсуждения
Fix for segfault in logical replication on master Mark Dilger <mark.dilger@enterprisedb.com>
RE: Fix for segfault in logical replication on master "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Re: Fix for segfault in logical replication on master Mark Dilger <mark.dilger@enterprisedb.com>
RE: Fix for segfault in logical replication on master "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Mark Dilger <mark.dilger@enterprisedb.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Mark Dilger <mark.dilger@enterprisedb.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Japin Li <japinli@hotmail.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Japin Li <japinli@hotmail.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Japin Li <japinli@hotmail.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>
Re: Fix for segfault in logical replication on master Japin Li <japinli@hotmail.com>
RE: Fix for segfault in logical replication on master "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Re: Fix for segfault in logical replication on master Amit Kapila <amit.kapila16@gmail.com>


> On Jun 17, 2021, at 3:39 AM, osumi.takamichi@fujitsu.com wrote:
> 
> For the 1st check, isn't it better to use RelationIsValid() ?

Yes, you are right.

> Additionally, In what kind of actual scenario, did you think that
> we come to the part to "log a complaint" ?

The way that RelationGetIndexList assigns rd_replidindex to the Relation seems to lack sufficient locking.  After scanning pg_index to find indexes associated with the relation, pg_index is closed and the access share lock released.  I couldn't prove to myself that by the time we use the rd_replidindex field thus computed that it was safe to assume that the Oid stored there still refers to an index.  The most likely problem would be that the index has since been dropped in a concurrent transaction, but it also seems just barely possible that the Oid has been reused and refers to something else, a table perhaps.  The check that I added is not completely bulletproof, because the new object reusing that Oid could be a different index, and we'd be none the wiser.  Do you think we should do something about that?  I felt the checks I put in place were very cheap and would work in almost all cases.  In any event, they seemed better than no checks, which is what we have now.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company





В списке pgsql-hackers по дате отправления
От: Dilip Kumar
Дата:
От: Tom Lane
Дата:
FAQ