Обсуждение: [9.2] Confusion over CacheRegisterSyscacheCallback

Commit b5282aa893: "Revise sinval code to remove no-longer-used tuple TID from inval messages."

dropped ItemPointer from callbacks and replaced it with "hashValue".
There seems to be 2 ways that new backend code calculates it:

- hashoid(oid), which seems to assume too much?
- CatalogCacheComputeTupleHashValue(), which is 'static'.

So my question is that after doing generic SearchSysCache() like:
  tup = SearchSysCache(USERMAPPINGUSERSERVER,       ObjectIdGetDatum(user_mapping->userid),
ObjectIdGetDatum(foreign_server->serverid),      0, 0);
 

what is the proper way to calculate the hashValue that 
will be given to callback?

-- 
marko

Marko Kreen <markokr@gmail.com> writes:
> So my question is that after doing generic SearchSysCache() like:

>    tup = SearchSysCache(USERMAPPINGUSERSERVER,
>         ObjectIdGetDatum(user_mapping->userid),
>         ObjectIdGetDatum(foreign_server->serverid),
>         0, 0);

> what is the proper way to calculate the hashValue that 
> will be given to callback?

Why would you need to know that?  The reason the calculation function
is static is that there's no apparent need to expose that information
outside the syscache subsystem.
        regards, tom lane

On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > So my question is that after doing generic SearchSysCache() like:
> 
> >    tup = SearchSysCache(USERMAPPINGUSERSERVER,
> >         ObjectIdGetDatum(user_mapping->userid),
> >         ObjectIdGetDatum(foreign_server->serverid),
> >         0, 0);
> 
> > what is the proper way to calculate the hashValue that 
> > will be given to callback?
> 
> Why would you need to know that?  The reason the calculation function
> is static is that there's no apparent need to expose that information
> outside the syscache subsystem.

Because I need to invalidate my own internal state that corresponds
to particular system catalog row?

In current case (plproxy) I need to invalidate libpq connections
that are created from particular foreign server entry.

-- 
marko

Marko Kreen <markokr@gmail.com> writes:
> On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
>> Why would you need to know that?  The reason the calculation function
>> is static is that there's no apparent need to expose that information
>> outside the syscache subsystem.

> Because I need to invalidate my own internal state that corresponds
> to particular system catalog row?

> In current case (plproxy) I need to invalidate libpq connections
> that are created from particular foreign server entry.

[ shrug... ] You could just flush 'em all, which is what most existing
inval callbacks do.  Admittedly a libpq connection is a bit more
expensive than the average bit of invalidatable state, but how often
does pg_foreign_server get updated?

Or you could do like setrefs.c does, and assume you know how to
calculate the hash value for an OID-keyed cache.
        regards, tom lane

On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> >> Why would you need to know that?  The reason the calculation function
> >> is static is that there's no apparent need to expose that information
> >> outside the syscache subsystem.
> 
> > Because I need to invalidate my own internal state that corresponds
> > to particular system catalog row?
> 
> > In current case (plproxy) I need to invalidate libpq connections
> > that are created from particular foreign server entry.
> 
> [ shrug... ] You could just flush 'em all, which is what most existing
> inval callbacks do.  Admittedly a libpq connection is a bit more
> expensive than the average bit of invalidatable state, but how often
> does pg_foreign_server get updated?

The frequency does not matter, it's the impact of what happens
when it does get updated.  There may be many connections.

> Or you could do like setrefs.c does, and assume you know how to
> calculate the hash value for an OID-keyed cache.

Ok, the hashoid() hack works.  But please take it as report from
the ground that this API is useful outside of core and it would
be good if it stays useful.

-- 
marko

Marko Kreen <markokr@gmail.com> writes:
> On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
>> Or you could do like setrefs.c does, and assume you know how to
>> calculate the hash value for an OID-keyed cache.

> Ok, the hashoid() hack works.  But please take it as report from
> the ground that this API is useful outside of core and it would
> be good if it stays useful.

Well, you have a point there --- what setrefs.c is doing is already
pretty grotty, and it would get more so if we added tracking of other
objects that used non-OID cache keys (though I'm not sure what those
would be).

We could expose some macros patterned after SearchSysCacheN that
take a cache identifier plus the same key values that would be
needed to search that cache, and return the hash value.  Does that
seem reasonable?
        regards, tom lane

On Wed, Mar 07, 2012 at 11:16:06AM -0500, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
> >> Or you could do like setrefs.c does, and assume you know how to
> >> calculate the hash value for an OID-keyed cache.
> 
> > Ok, the hashoid() hack works.  But please take it as report from
> > the ground that this API is useful outside of core and it would
> > be good if it stays useful.
> 
> Well, you have a point there --- what setrefs.c is doing is already
> pretty grotty, and it would get more so if we added tracking of other
> objects that used non-OID cache keys (though I'm not sure what those
> would be).
> 
> We could expose some macros patterned after SearchSysCacheN that
> take a cache identifier plus the same key values that would be
> needed to search that cache, and return the hash value.  Does that
> seem reasonable?

Yes.

-- 
marko