Re: Segfault on logical replication to partitioned table with foreign children
От | Tom Lane |
---|---|
Тема | Re: Segfault on logical replication to partitioned table with foreign children |
Дата | |
Msg-id | 188734.1667137161@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Segfault on logical replication to partitioned table with foreign children (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
RE: Segfault on logical replication to partitioned table with foreign children
Re: Segfault on logical replication to partitioned table with foreign children Re: Segfault on logical replication to partitioned table with foreign children |
Список | pgsql-hackers |
Dilip Kumar <dilipbalaut@gmail.com> writes: > Yes, this looks like a bug and your fix seems correct to me. It would > be nice to add a test case for this scenario. A test case doesn't seem that exciting to me. If we were trying to make it actually work, then yeah, but throwing an error isn't that useful to test. The code will be exercised by replication to a regular partitioned table (I assume we do have tests for that). What I'm wondering about is whether we can refactor this code to avoid so many usually-useless catalog lookups. Pulling the namespace name, in particular, is expensive and we generally are not going to need the result. In the child-rel case it'd be much better to pass the opened relation and let the error-check subroutine work from that. Maybe we should just do it like that at the start of the recursion, too? Or pass the relid and let the subroutine look up the names only in the error case. A completely different line of thought is that this doesn't seem like a terribly bulletproof fix, since children could get added to a partitioned table after we look. Maybe it'd be better to check the relkind at the last moment before we do something that depends on a child table being a relation. regards, tom lane
В списке pgsql-hackers по дате отправления: