On Tue, Nov 30, 2021 at 6:44 AM Andy Fan <zhihui.fan1...@gmail.com> wrote:
>>
>>
>>>
>>> Why do you think this ought to be in the relcache, and not in the
>>> executor's rangetable-associated data structures?
>
>
> I re-think about this, I guess I didn't mention something clear enough.
> That's true that I bound my bala struct to Relation struct, and the memory
> relation used is allocated in relcache. but the memory of bala is allocated
> in
> TopTransactionMemory context.
>
> xxx_table_tuple_insert(Relation rel, ...)
> {
> if (rel->balabala == NULL)
> rel->balabala = allocate_bala_resource(rel); //
> TopTransactionContext.
> do_task_with(rel->balabala);
> }
>
> not sure if this should be called as putting my data in relcache.
>
> and I rechecked the RelationData struct, and it looks like some Executor-bind
> struct also
> resides in it. for example: RelationData.rd_lookInfo. If the relcache can be
> reset, the
> fields like this are unsafe to access as well. Am I missing something?
I think you are talking about rd_lockInfo? first, think this is not a
pointer so even if you get a new recache entry this memory will be
allocated along with the new relation descriptor and it will be
initialized whenever a new relation descriptor is created check
RelationInitLockInfo(). You will see there are many pointers also in
RelationData but we ensure before we access them they are initialized,
and most of them are allocated while building the relation descriptor
see RelationBuildDesc().
So if you keep some random pointer in RelationData without ensuring
that is getting reinitialized while building the relation cache then I
think that's not the correct way to do it.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
