Re: hyrax vs. RelationBuildPartitionDesc
От | Tom Lane |
---|---|
Тема | Re: hyrax vs. RelationBuildPartitionDesc |
Дата | |
Msg-id | 7961.1552498252@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: hyrax vs. RelationBuildPartitionDesc (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: hyrax vs. RelationBuildPartitionDesc
|
Список | pgsql-hackers |
I wrote: > I recall having noticed someplace where I thought the relcache partition > support was simply failing to make provisions for cleaning up a cached > structure at relcache entry drop, but I didn't have time to pursue it > right then. Let me see if I can reconstruct what I was worried about. Ah, here we are: it was rel->rd_partcheck. I'm not sure exactly how complicated that structure can be, but I'm pretty sure that this is a laughably inadequate method of cleaning it up: if (relation->rd_partcheck) pfree(relation->rd_partcheck); Having it be loose data in CacheMemoryContext, which is the current state of affairs, is just not going to be practical to clean up. I suggest that maybe it could be copied into rd_partkeycxt or rd_pdcxt, so that it'd go away as a byproduct of freeing those. If there's a reason it has to be independent of both, it'll have to have its own small context. Dunno if that's related to hyrax's issue, though. regards, tom lane
В списке pgsql-hackers по дате отправления: