RE: ResourceOwner refactoring - Mailing list pgsql-hackers

From kuroda.hayato@fujitsu.com
Subject RE: ResourceOwner refactoring
Date
Msg-id OSBPR01MB31575D0055E4B75F836CA16CF5A70@OSBPR01MB3157.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: ResourceOwner refactoring  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses RE: ResourceOwner refactoring  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Dear Heikki,

> Hmm. ResOwnerReleaseTupleDesc() does exist, those functions are needed 
> for the callbacks. I think you meant the wrappers around 
> ResourceOwnerRemember and ResourceOwnerForget, like 
> ResourceOwnerRememberCatCacheRef(). I admit those are not fully 
> consistent: I didn't bother with the wrapper functions when there is 
> only one caller.

Yeah, I meant it. And I prefer your policy.

> Hmm. ResOwnerReleaseTupleDesc() does exist, those functions are needed 
> for the callbacks. I think you meant the wrappers around 
> ResourceOwnerRemember and ResourceOwnerForget, like 
> ResourceOwnerRememberCatCacheRef(). I admit those are not fully 
> consistent: I didn't bother with the wrapper functions when there is 
> only one caller.

Good job. I confirmed your fixes, and I confirmed it looks fine.
I will check another ResourceOwnerEnlarge() if I have a time.

> I've been working on performance testing too.

I'm looking forward to seeing it.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: fdatasync(2) on macOS
Next
From: japin
Date:
Subject: Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION